Re: [net-next PATCH v4 0/8] Managing the forwarding database(FDB)
From: John Fastabend <hidden>
Date: 2012-05-05 05:00:10
On 5/4/2012 1:34 PM, Roopa Prabhu wrote:
On Thu, May 3, 2012 at 10:43 PM, Sridhar Samudrala <sri@us.ibm.com <mailto:sri@us.ibm.com>> wrote:
On 5/3/2012 12:38 PM, John Fastabend wrote:
On 5/2/2012 4:36 PM, Sridhar Samudrala wrote:
On 5/2/2012 2:52 PM, John Fastabend wrote:
On 5/2/2012 8:08 AM, Michael S. Tsirkin wrote:
On Sun, Apr 15, 2012 at 01:06:37PM -0400, David Miller wrote:
From: John Fastabend<john.r.fastabend@__intel.com <mailto:john.r.fastabend@intel.com>>
Date: Sun, 15 Apr 2012 09:43:51 -0700
The following series is a submission for net-next to allow
embedded switches and other stacked devices other then the
Linux bridge to manage a forwarding database.
Previously discussed here,
http://lists.openwall.net/__netdev/2012/03/19/26 <http://lists.openwall.net/netdev/2012/03/19/26>
v4: propagate return codes correctly for ndo_dflt_Fdb_dump()
v3: resolve the macvlan patch 8/8 to fix a dev_set_promiscuity()
error and add the flags field to change and get link routines.
v2: addressed feedback from Ben Hutchings resolving a typo in the
multicast add/del routines and improving the error handling
when both NTF_SELF and NTF_MASTER are set.
I've tested this with 'br' tool published by Stephen Hemminger
soon to be renamed 'bridge' I believe and various traffic
generators mostly pktgen, ping, and netperf.
All applied, if we need any more tweaks we can just add them
on top of this work.
Thanks John.
John, do you plan to update kvm userspace to use this interface?
No immediate plans. I would really appreciate it if you or one
of the IBM developers working in this space took it on. Of course
if no one steps up I guess I can eventually get at it but it will
be sometime. For now I've been doing this manually with the bridge
tool yet to be published.
Does this mean that when we add an interface to a bridge, it need not be put in promiscuous mode and
add/delete fdb entries dynamically?
The net/bridge will automatically put the interface in promisc mode
when the device is attached. We do need to add/delete fdb entries
though to allow forwarding packets from the virtual function and
any emulated devices e.g. tap devices on the bridge.
Consider the following scenario where we have a SR-IOV NIC with 1 PF
and 2 VFs (VF1 & VF2).
- eth0 is the PF which is attached to bridge br0 and connected to 2 VMs VM1 and VM2.
- eth1 is the VF1 terminated on the host and assigned to VM3 via macvtap0 in passthru mode.
- VF2 is directly assigned to VM4 via pci-device assignment.
VM1 VM2 VM3 VM4
(mac1) (mac2) (mac3) (mac4)
| | | |
| | | |
vnet0 vnet1 | |
| | | |
\ / | |
\ / | |
br0 macvtap0 |
| (mac3) |
| | |
eth0 eth1 |
| (mac3) |
| | |
------------------------------__------
| PF VF1 VF2 |
| |
| VEB |
------------------------------__------
In this setup, i think when VM1 and VM2 come up, mac1 and mac2 have to be added to the
embedded bridge's fdb. Once we add these 2 entries, all the 4 VMs can talk to each other.
Is this correct?Correct as Roopa indicated.
Now, if VM1 or VM2 wants to add secondary mac addresses, i think we need qemu to add a new fdb
entry when it receives add mac address command via virtio control vq.
yes. I had used (with some tweaks) some existing qemu patches on patchwork to try this out with my implementation.
The links to the patches on patchwork are listed in my cover mail at http://marc.info/?l=linux-netdev&m=131534911001054&w=2 <http://marc.info/?l=linux-netdev&m=131534911001054&w=2>
Can we add multiple mac addresses to VFs? For example VM3 and VM4 trying to add a secondary mac address.Yes this is why we also added the fdb interface to the macvlan device as well.
What about VMs trying to create VLANs? I think this will work on VM1 and VM2. However with VM3
and VM4, i think we need qemu to add vlans to the VFs when the VMs create them.
yes for vlans too, the qemu patches pointed out above can be reused.
Thanks,
Roopa