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
| ||
|
Message-ID: <4FA36C78.80509@us.ibm.com> Date: Thu, 03 May 2012 22:43:20 -0700 From: Sridhar Samudrala <sri@...ibm.com> To: John Fastabend <john.r.fastabend@...el.com> CC: Roopa Prabhu <roopa.prabhu@...il.com>, "Michael S. Tsirkin" <mst@...hat.com>, shemminger@...tta.com, bhutchings@...arflare.com, hadi@...erus.ca, jeffrey.t.kirsher@...el.com, netdev@...r.kernel.org, gregory.v.rose@...el.com, krkumar2@...ibm.com Subject: Re: [net-next PATCH v4 0/8] Managing the forwarding database(FDB) 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@...el.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 >>>>>> >>>>>> 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? 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. Can we add multiple mac addresses to VFs? For example VM3 and VM4 trying to add a secondary mac address. 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. Thanks Sridhar -- 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
Powered by blists - more mailing lists