On Mon, 2012-03-12 at 09:48 +0100, Lennert Buytenhek wrote:
Since it can lead to problems (address database mismatches, doesn't
correctly handle STP transitions or topology changes automatically),
I think it should be avoided whenever possible. I don't see any
advantages of hardware based
On Tue, 2012-03-06 at 15:09 +0100, Lennert Buytenhek wrote:
Why so? (I think the switch chips should just never do learning at
all..)
I agree that learning in software gives you more flexibility; however,
I am for providing interface flexibility as well - switches have
learning features. I
On Wed, 2012-02-29 at 09:25 -0800, John Fastabend wrote:
Well I think NETLINK_ROUTE is the most correct type to use in this
case. Per netlink.h its for routing and device hooks.
#define NETLINK_ROUTE 0 /* Routing/device hook
*/
And NETLINK_ROUTE
On Wed, 2012-02-29 at 10:19 -0800, John Fastabend wrote:
I want to see a unified API so that user space control applications (RSTP,
TRILL?)
can use one set of netlink calls for both software bridge and hardware
offloaded
bridges. Does this proposal meet that requirement?
I
On Tue, 2012-02-28 at 20:40 -0800, John Fastabend wrote:
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 -
On Tue, 2012-02-28 at 21:14 -0800, John Fastabend wrote:
Just checked looks like the DSA infrastructure has commands to enable
STP so guess it is doing learning.
IIRC, Lennert built some of this stuff tied to the kernel.
cheers,
jamal
--
To unsubscribe from this list: send the line
On Tue, 2012-02-14 at 10:57 -0800, John Fastabend wrote:
Roopa was likely on the right track here,
http://patchwork.ozlabs.org/patch/123064/
Doesnt seem related to the bridging stuff - the modeling looks
reasonable however.
But I think the proper syntax is to use the existing
