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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1329488932.2272.19.camel@mojatatu>
Date:	Fri, 17 Feb 2012 09:28:52 -0500
From:	jamal <hadi@...erus.ca>
To:	John Fastabend <john.r.fastabend@...el.com>
Cc:	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
Subject: Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into
 hardware

On Wed, 2012-02-15 at 17:26 -0800, John Fastabend wrote:
> On 2/15/2012 6:10 AM, Jamal Hadi Salim wrote:
> > 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.
> > 
> 
> The operations are really the same ADD/DEL/GET additional MAC
> addresses to a port, in this case a macvlan type port. The
> difference is the  macvlan port type drops any packet with an
> address not in the FDB where the bridge type floods these.

Ok.
[the vlan piece really should have been an integrated part of bridging;
in the early days this was the case]

> [root@...dev1-dcblab src]# br fdb help
> Usage: br fdb { add | del | replace } ADDR dev DEV
>        br fdb {show} [ dev DEV ]
> 
> In my example I just dumped all bridge devices,
> 

Ok, makes sense.

> Seems we need both a synchronize and a { add | del | replace } option.

I am conflicted on this.
Not sure if that is a command line thing or something built into a user
space daemon. It may be useful to have the command line variant but i
feel having a daemon take care of things helps in faster
synchronization.
I think user space is a good spot to add such functionality (as opposed
to the kernel). That way user space can work with h/ware switching such
as yours as well as a standalone switching chips (from sillicon vendors
like Marvel etc).
IMO, the average user doesnt need to be aware of such low level stuff;
so the default should be for the user not to be responsible for
configuration of synchronization. IOW, I want to just run well
understood user interface tools things like ifconfig, ip link etc, the
new br tool and not even need to be aware that we are offloading.
So as long as s/w br0 is mapping to the bridge on ixgb-0 i dont need
to know ixgb0 h/w bridge exists.

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.

> So I think what your saying is a per port bit to disable learning...
> hmm but if you start tweaking it too much it looks less and less like a
> 802.1D bridge and more like something you would want to build with tc or
> openvswitch or tc+bridge or tc+macvlan.

These are pretty commodity features in most silicon switching chips ive
come across. You have a knob to control learning and another to control
flooding.

cheers,
jamal

--
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