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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 03 May 2012 22:43:20 -0700
From:	Sridhar Samudrala <>
To:	John Fastabend <>
CC:	Roopa Prabhu <>,
	"Michael S. Tsirkin" <>,,,,,,,
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<>
>>>>> 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,
>>>>>> 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.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists