Re: Netlink API for bonding ?

["Nicolas de Pesloüan" <nicolas.2p.debian@free.fr>]

Stephen Hemminger wrote:
> On Mon, 31 Aug 2009 22:34:50 +0200
> Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote:
> 
>> Stephen,
>>
>> Can you please describe the netlink API you plan to implement for bonding ?
>>
>> Both Jiri Pirko and I plan to add some advanced active slave selection rules, 
>> for more-than-two-slaves bonding configuration.
>>
>> Jay suggested that such advanced features be implemented in user space, using 
>> netlink to notify a daemon when slaves come up or fall down. I agree with Jay, 
>> but don't want to design something without having first a view at your proposed 
>> API for bonding.
>>
>> Do you plan to have some notification to user space, or only the ability to read 
>> and set bonding configuration using netlink ?
>>
>> Thanks,
>>
>> 	Nicolas.
> 
> No paper spec, but was looking to add interface similar to vlan and macvlan.
> Just use (and extend if needed) existing rtnl_link_ops.
> 
> 
> Was not planning on adding a notification interface, thats good idea but
> really not what I was looking at.

What kind of notification system would you suggest to notify userland that a 
given bond device just lose the current active slave ?

1/ Adding to the list of broadcast group (RTMGRP_*) for NETLINK_ROUTE protocol 
in include/linux/rtnetlink.h.

2/ Registering a new NETLINK protocol NETLINK_BONDING in include/linux/netlink.h 
and one of more broadcast groups for this new protocol ?

3/ Not using a broadcast group for notification, but expecting userland to 
register with the driver using a rtnl_link_ops attribut, to give its PID, so the 
driver can then send unicast netlink message to userland which would bind() on 
NETLINK_ROUTE  ?

4/ Using NETLINK_GENERIC in some ways ?

Also, we need a way to ensure that userland is still available to decide 
quickly what to do when the active slave disappear. At least some sort of 
timeout, that, when elapsed, would cause bonding driver to fall back to the 
normal behavior.

Should the notification message hold all the available information about the 
current status of the bonding device, so that userland is able to decide 
quickly, without asking the driver to provide extra information ? This would 
require the receiving buffer to be very large, and with a variable length, 
because the status length depends on the number of slaves for this particular 
bonding device. Not really nice...

Another way would be to simply notify userland that "something happens to bond 
device bondX", and expect userland to ask for the information, by first asking 
for the buffer size, then asking to fill the buffer. This would lead to some 
extra process time, that might be too long to be acceptable to select a new 
active slave.

Any comments ?

	Nicolas.