netdev - Switchdev Application to SR-IOV NICs

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

Message-ID: <3A5015FE9E557D448AF7238AF0ACE20A2D8ACC6F@IRVEXCHMB11.corp.ad.broadcom.com>
Date:	Wed, 4 Mar 2015 00:26:22 +0000
From:	David Christensen <davidch@...adcom.com>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	Jiří Pírko (jiri@...nulli.us) 
	<jiri@...nulli.us>
Subject: Switchdev Application to SR-IOV NICs

I'm struggling with the concept of implementing switchdev on an SR-IOV NIC.
Most slides presented at Netdev 0.1 agreed that switchdev should be applicable
to SR-IOV NICs as well as switch ASICs, but I'm having difficulty figuring
out exactly how things should operate.  Here's how things look today with
netdev and SR-IOV VFs passed-through to a virtual machine.

      +-----+-----+-----+
      | vm0 | vm1 | vm2 | Virtual
      | eth0| eth0| eth0| Machines
+-----+--|--+--|--+--|--+----------
|eth0 |  |     |     |    Kernel
+--|--+--|-----|-----|--+----------
| pf0   vf0   vf1   vf2 | PCIe
+--|-----|-----|-----|--+----------
| ++-----+-----+-----++ | SR-IOV NIC
| | VEB               | |
| +------------+------+ |
+--------------|--------+
               |
              PHY

Connectivity between VMs and the host is handled by the VEB operating in the
NIC, other traffic is forwarded normally by the VEB from the external network
to the host/VM based on destination MAC and VLAN with special handling 
required for broadcast/multicast.  

Based on some separate conversations I've had with Jiri, I'm lead to believe
switchdev would look something like this.

      +-----+-----+-----+
      | vm0 | vm1 | vm2 | Virtual
      | eth0| eth0| eth0| Machines
+-----+--|--+--|--+--|--+----------
|sw0p0 sw0p1 sw0p2 sw0p3| Kernel
+--|-----|-----|-----|--+----------
| pf0   vf0   vf1   vf2 | PCIe
+--|-----|-----|-----|--+----------
| ++-----+-----+-----++ | SR-IOV NIC
| | VEB               | |
| +------------+------+ |
| SR-IOV NIC   |        |
+--------------|--------+
               |
              PHY

The use of switchdev would show that all sw0* devices are associated with the
same switch, and the instantiation of the sw0* devices in the kernel would
provide higher level applications like OVS/Linux bridge/etc. to control traffic
in a way not possible in the earlier example.  So far so good?

Now the question becomes how to plumb SR-IOV NIC to create this representation.
Looking at one specific path:

  +-----+
  | vm0 |
  | eth0|
  +--|--+
  |sw0p1|
  +--|--+
  | vf0 |
+----|----+
| +--+--+ |
| | VEB | |
| +-----+ |
+---------+

It's unclear to me when traffic egressing the VEB should terminate at sw0p1 vs.
vm0's eth0.  They both represent the same MAC/VLAN.  Similarly, for traffic 
egressing vm0's eth0, when should it terminate at sw0p1 vs. the VEB.

Can anyone offer an alternate diagram for switchdev on an SR-IOV NIC?

Dave
--
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