Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

[John Fastabend <john.r.fastabend@intel.com>]

On 2/9/2012 1:11 PM, jamal wrote:
> On Thu, 2012-02-09 at 09:52 -0800, John Fastabend wrote:
> 
>>>> By netlink_notifier do you mean adding a notifier_block and using atomic_notifier_call_chain()
>>>> probably in rtnl_notify()? Then drivers could register with the notifier chain with
>>>> atomic_notifier_chain_register() and receive the events correctly. Or did I miss
>>>> some notifier chain that already exists?
>>>
>>> Yes. that is what I mean. The callbacks you need may or may not already be present.
> 
> I'll go one step further.
> This stuff shouldnt be in the kernel at all. 
> The disadvantage is you need a user space app to update the hardware.
> i.e, the same mechanism should be usable for either a switch embedded
> in a NIC or a standalone hardware switch (with/out the s/ware bridge 
> presence)
> 
> cheers,
> jamal
> 

Hi Jamal,

The user space app in this case would listen for FDB updates to the SW
bridge and then mirror them at the embedded NIC. In this case it seems
easier to just add a notifier chain and let the kernel keep these in
sync. Otherwise we need a daemon in user space to replicate these.

On the other hand if you could make the same RTM_NEWNEIGH, RTM_DELNEIGH,
and RTM_GETNEIGH work for the bridge, embedded bridge, and macvlan you
would have one common interface to drive these. But the bridge already
has this protocol/msgtype so that would require either some demux or
new protocol/msgtype pairs to be created. 

Let me think on it. I'm tempted by the simplicity of adding notifier
hooks though.

.John