netdev - Re: [net-next PATCH v4 0/8] Managing the forwarding database(FDB)

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] [day] [month] [year] [list]

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