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 PF_BRIDGE:
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 "unsubsc
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_
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
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 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
