[Ksummit-2008-discuss] proposal for discussion..

Evgeniy Polyakov johnpol at 2ka.mipt.ru
Mon Aug 25 14:33:27 PDT 2008


Hi Marcel.

On Mon, Aug 25, 2008 at 11:15:30PM +0200, Marcel Holtmann (holtmann at linux.intel.com) wrote:
> >You will have to put new socket(AF_DBUS) call instead of AF_UNIX into
> >any binding (or appropriate underlying library), so you can just  
> >replace
> >it with netlink.
> 
> true, but then I have to pass the D-Bus message and convert it to a  
> netlink message. I really don't wanna do this, but I open for  

No, I do not think its that bad. The simplest way is just to wrap dbus
messages into netlink ones and put couple of handler to trim/add
netlink headers before the dbus ones. Further extension can also be
done, and this may require complex changes in the dbus message format.

> suggestions here. However wrapping the D-Bus wire format into another  
> protocols wire format seems wrong to me.

Why? We have, for example, wireless configuration protocol, which is
wrapped on top of netlink. It is also quite separate subsystem which
could also be implemented as own socket family. But why is it needed? It
can be perfectly wrapped without need to reinvent lots of low level
socket machinery. Wireless configuration is of course simpler and
smaller than dbus, but I belive such approach also applies to dbus.

> >It is pretty unlikely imho that such zero-copy approach for small  
> >enough
> >dbus messages will have any benefit.
> 
> Actually zerocopy is only one reason for me. The latency improvements  
> and less context switches are also a point for me.

Well, netlink has only single switch when data has been put into the
socket queue and appropriate userspace application is awakened. Sending
does not have context switch in the very most cases (there are tricks
when the same group is being shared and currently handled by another
kernel->userspace dataflow).

> That would be a discussion point. Currently I am not sold on it, but  
> that might change since I haven't looked into it in details. However D- 
> Bus also has a manager component to assign unique and well known bus  
> names. So this needs some further investigation. The prototype I am  
> working is using AF_DBUS.

I would call dbus names as internet host names while netlink addresses
are LAN MACs. Other machines on the very remote end will have some own
transport to deliver dbus messages to its users, and while they are read
from the network (tcp/udp or just ip for example) socket, locally they
are read from the netlink socket (where it is supported).

That's all is a discussion point of course...

-- 
	Evgeniy Polyakov


More information about the Ksummit-2008-discuss mailing list