Message-ID: <4F4DB440.50509@intel.com>
Date:	Tue, 28 Feb 2012 21:14:40 -0800
From:	John Fastabend <john.r.fastabend@...el.com>
To:	jhs@...atatu.com
CC:	jamal <hadi@...erus.ca>, Stephen Hemminger <shemminger@...tta.com>,
	bhutchings@...arflare.com, roprabhu@...co.com,
	netdev@...r.kernel.org, mst@...hat.com, chrisw@...hat.com,
	davem@...emloft.net, gregory.v.rose@...el.com, kvm@...r.kernel.org,
	sri@...ibm.com, kernel@...tstofly.org
Subject: Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

On 2/28/2012 8:40 PM, John Fastabend wrote:
> On 2/18/2012 4:41 AM, jamal wrote:
>> On Fri, 2012-02-17 at 09:10 -0800, John Fastabend wrote:
>>
>>> Yes I agree that is the goal.
>>>
>>>> One last comment:
>>>> With synchronization there are other challenges when the entry in the
>>>> hardware conflicts with the entry in software when you intend the
>>>> behavior to be the same. This is not such a big deal with bridging but
>>>> becomes more apparent when you start offloading ACLs etc.
>>>>
>>>
>>> OK and these sorts of conflicts certainly don't need to be resolved
>>> by kernel code. So I think this is a reasonable reason to drive the
>>> synchronization into a user space daemon.
>>
>>
>> Yep. 
>> Thanks for listening John. Waiting to see them patches.
>>
>> cheers,
>> jamal
>>
>>
>>
> 
> +Lennert
> 
> OK back to this. The last piece is where to put these messages...
> we could take PF_ROUTE:RTM_*NEIGH
> 
>      PF_ROUTE:RTM_NEWNEIGH - Add a new FDB entry to an offloaded
>                              switch.
>      PF_ROUTE:RTM_DELNEIGH - Delete a FDB entry from an offlaoded
>                              switch.
>      PF_ROUTE:RTM_GETNEIGH - Dumps the embedded FDB table
> 
> The neighbor code is using the PF_UNSPEC protocol type so we won't
> collide with these unless someone was using PF_ROUTE and relying on
> falling back to PF_UNSPEC however I couldn't find any programs that
> did this iproute2 certainly doesn't. And the bridge pieces are using
> PF_BRIDGE so no collision there.
> 
> I briefly thought about trying to pull the PF_BRIDGE protocol out
> and use this for both types but I think its better to leave the
> bridge code alone and there is also the issue of disambiguating a msg
> at a port which has both an embedded switch and has SW bridge for a
> master.

Maybe I gave up too quickly here I could use a bit in the ndm_flags to
specify embedded or sw bridge. But would require having the bridge
module loaded.

> 
> Also if there are embedded switches with learning capabilities they
> might want to trigger events to user space. In this case having
> a protocol type makes user space a bit easier to manage. I've
> added Lennert so maybe he can comment I think the Marvell chipsets
> might support something along these lines. The SR-IOV chipsets I'm
> aware of _today_ don't do learning. Learning makes the event model
> more plausible.
> 

Just checked looks like the DSA infrastructure has commands to enable
STP so guess it is doing learning.

> The other mechanism would be to embed some more attributes into the
> PF_UNSPEC:RTM_XXXLINK msg however I'm thinking that if we want to
> support learning and triggering events then we likely also don't
> want to send these events to every app with RTNLGRP_LINK set.
> 
> Plus there is already a proliferation of LINK attributes and dumping
> the FDB out of this seems a bit much but could be done with some
> bitmasks. Although the current ext_filter_mask u32 doesn't seem to
> be sufficient for events to trigger this.
> 
> so much for a short note...
> 
> Thanks
> .John
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists