Lines Matching +full:network +full:- +full:on +full:- +full:chip
1 .. SPDX-License-Identifier: GPL-2.0
5 Network Function Representors
9 used to control internal switching on SmartNICs. For the closely-related port
10 representors on physical (multi-port) switches, see
14 ----------
16 Since the mid-2010s, network cards have started offering more complex
17 virtualisation capabilities than the legacy SR-IOV approach (with its simple
18 MAC/VLAN-based switching model) can support. This led to a desire to offload
19 software-defined networks (such as OpenVSwitch) to these NICs to specify the
20 network connectivity of each function. The resulting designs are variously
23 Network function representors bring the standard Linux networking stack to
24 virtual switches and IOV devices. Just as each physical port of a Linux-
42 -----------
45 which has administrative control over the virtual switch on the device.
48 Depending on NIC design, a multi-port NIC might have a single switchdev function
50 switchdev function, for each physical network port.
53 only create representors for the ports on the (sub-)switch it directly
60 ---------------------------
64 1. It is used to configure the network connection the representee sees, e.g.
67 on event.
69 fast-path rules in the virtual switch. Packets transmitted on the
72 be received on the representor netdevice. (That is, there is a virtual pipe
76 bridge) to forward packets between representees and the rest of the network.
82 on a VF representor applies in software to packets received on that representor
88 -----------------------------------------
90 Essentially, for each virtual port on the device's internal switch, there
93 network port, which can simplify usage (the uplink netdev becomes in effect the
99 - VFs belonging to the switchdev function.
100 - Other PFs on the local PCIe controller, and any VFs belonging to them.
101 - PFs and VFs on external PCIe controllers on the device (e.g. for any embedded
102 System-on-Chip within the SmartNIC).
103 - PFs and VFs with other personalities, including network block devices (such
104 as a vDPA virtio-blk PF backed by remote/distributed storage), if (and only
105 if) their network access is implemented through a virtual switch port. [#]_
108 - Subfunctions (SFs) belonging to any of the above PFs or VFs, if they have
109 their own port on the switch (as opposed to using their parent PF's port).
110 - Any accelerators or plugins on the device whose interface to the network is
121 A PCIe function which does not have network access through the internal switch
131 translation between block DMA requests and network packets, so that only
132 network packets pass through the virtual port onto the switch. The network
138 Contrast this with the case of a virtio-blk implementation which forwards the
141 run over the virtual switch and the virtio-blk PF should thus *not* have a
145 -----------------------------
148 port on the switch, create a pure-software netdevice which has some form of
149 in-kernel reference to the switchdev function's own netdevice or driver private
161 --------------------------------
164 through ``net_dev->dev.parent`` / ``SET_NETDEV_DEV()``), either of the
172 :ref:`Documentation/networking/devlink/devlink-port.rst <devlink_port>` for the
184 -------------------------------------------
186 Any TC rule on a representor applies (in software TC) to packets received by
188 to another port on the virtual switch, the driver may choose to offload it to
205 all IPv4 packets received on the physical port are delivered to the VF in
206 addition to ``PORT_DEV``. (Note that without ``skip_sw`` on the second rule,
207 the VF would get two copies, as the packet reception on ``PORT_DEV`` would
210 On devices without separate port and uplink representors, ``PORT_DEV`` would
213 Of course the rules can (if supported by the NIC) include packet-modifying
231 another IP address on the same subnet, mean that packets sent by the VF should
235 outer Ethernet frame), while UDP packets received on the physical port with UDP
246 ---------------------------------
249 representor administratively UP or DOWN should cause carrier ON or OFF at the
252 Setting an MTU on the representor should cause that same MTU to be reported to
254 (On hardware that allows configuring separate and distinct MTU and MRU values,
255 the representor MTU should correspond to the representee's MRU and vice-versa.)
260 - legacy SR-IOV (``ip link set DEVICE vf NUM mac LLADDR``)
261 - devlink port function (see **devlink-port(8)** and
262 :ref:`Documentation/networking/devlink/devlink-port.rst <devlink_port>`)