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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 09 Feb 2012 16:39:09 -0800
From:	Sridhar Samudrala <sri@...ibm.com>
To:	John Fastabend <john.r.fastabend@...el.com>
Cc:	bhutchings@...arflare.com, roprabhu@...co.com,
	netdev@...r.kernel.org, mst@...hat.com, chrisw@...hat.com,
	davem@...emloft.net, gregory.v.rose@...el.com,
	shemminger@...tta.com, kvm@...r.kernel.org
Subject: Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into
 hardware

On Thu, 2012-02-09 at 12:30 -0800, John Fastabend wrote:
> On 2/9/2012 10:14 AM, Sridhar Samudrala wrote:
> > On Wed, 2012-02-08 at 19:22 -0800, John Fastabend wrote:
> >> Propagate software FDB table into hardware uc, mc lists when
> >> the NETIF_F_HW_FDB is set.
> >>
> >> This resolves the case below where an embedded switch is used
> >> in hardware to do inter-VF or VF-PF switching. This patch
> >> pushes the FDB entry (specifically the MAC address) into the
> >> embedded switch with dev_add_uc and dev_add_mc so the switch
> >> "learns" about the software bridge.
> >>
> >>
> >>           veth0  veth2
> >>             |      |
> >>           ------------
> >>           |  bridge0 |   <---- software bridging
> >>           ------------
> >>                /
> >>                /
> >>   ethx.y      ethx
> >>     VF         PF
> >>      \         \          <---- propagate FDB entries to HW
> >>      \         \
> >>   --------------------
> >>   |  Embedded Bridge |    <---- hardware offloaded switching
> >>   --------------------
> >>
> > 
> > This scenario works now as adding an interface to a bridge puts it in
> > promiscuous mode. So adding a PF to a software bridge should not be
> > a problem as it supports promiscuous mode. But adding a VF will not
> > work.
> 
> It shouldn't work because the embedded bridge will lookup the address
> in its FDB and when it doesn't match any unicast filters it will forward
> the packet onto the wire. Because the veth0 and veth2 above never get
> inserted into the embedded brdige's FDB the packets will _never_ get
> routed there.
> 
> That said the current 'ixgbe' driver is doing something broken in that
> it is always setting the unicast hash table and mirroring bits to 1. So
> if you think this is working your seeing a bug where packets are being
> sent onto the wire AND upto the PF. Packets with destination addresses
> matching veth1 should not end up on the wire and vice versa. This is
> specific to ixgbe and is not the case for other SR-IOV devices.

OK. Is this behavior going to be fixed.

> 
> This causes some issues (a) has some very real performance implications,
> (b) at this point you have some strange behavior from my point of view.
> The embedded bridge is not a learning bridge nor is it acting like an
> 802.1Q VEB or VEPA.
> 
> > 
> > Are you trying to avoid the requirement of having to put the interface 
> > in promiscuous mode when adding to a bridge?
> > 
> 
> I think the bridge being in promiscuous mode is correct.

The interface that is added to the bridge is put in promiscuous mode,
not the bridge itself.  In this example, i assumed that setting
promiscuous on PF is putting the embedded bridge in learning mode.

Thanks
Sridhar

> 
> Hope that helps sorry its a bit long winded.
> 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