On 15-Aug-22 16:22, ecree@xxxxxxxxxx wrote: > [...] > > +Motivation > +---------- > + > +Since the mid-2010s, network cards have started offering more complex > +virtualisation capabilities than the legacy SR-IOV approach (with its simple > +MAC/VLAN-based switching model) can support. This led to a desire to offload > +software-defined networks (such as OpenVSwitch) to these NICs to specify the > +network connectivity of each function. The resulting designs are variously > +called SmartNICs or DPUs. > + > +Network function representors bring the standard Linux networking stack to > +virtual switches and IOV devices. Just as each port of a Linux-controlled > +switch has a separate netdev, so each virtual function has one. When the system Maybe I'm misunderstanding something, but this sentence seems a bit confusing. Maybe: "Just as each port of a Linux-controlled switch has a separate netdev, each virtual function has one."? > +boots, and before any offload is configured, all packets from the virtual > +functions appear in the networking stack of the PF via the representors. > +The PF can thus always communicate freely with the virtual functions. > +The PF can configure standard Linux forwarding between representors, the uplink > +or any other netdev (routing, bridging, TC classifiers). > > [...] > > +How do representors interact with TC rules? > +------------------------------------------- > + > +Any TC rule on a representor applies (in software TC) to packets received by > +that representor netdevice. Thus, if the delivery part of the rule corresponds > +to another port on the virtual switch, the driver may choose to offload it to > +hardware, applying it to packets transmitted by the representee. > + > +Similarly, since a TC mirred egress action targeting the representor would (in > +software) send the packet through the representor (and thus indirectly deliver > +it to the representee), hardware offload should interpret this as delivery to > +the representee. > + > +As a simple example, if ``eth0`` is the master PF's netdevice and ``eth1`` is a > +VF representor, the following rules:: > + > + tc filter add dev eth1 parent ffff: protocol ipv4 flower \ > + action mirred egress redirect dev eth0 > + tc filter add dev eth0 parent ffff: protocol ipv4 flower \ > + action mirred egress mirror dev eth1 Perhaps eth0/eth1 names could be replaced with more meaningful names, as it's easy to confuse them now. How about examples from above (e.g. PF -> eth4, PR -> eth4pf1vf2rep)? Or just $PF_NETDEV, $PR_NETDEV. > +would mean that all IPv4 packets from the VF are sent out the physical port, and > +all IPv4 packets received on the physical port are delivered to the VF in > +addition to the master PF. > + > +Of course the rules can (if supported by the NIC) include packet-modifying > +actions (e.g. VLAN push/pop), which should be performed by the virtual switch. > + > +Tunnel encapsulation and decapsulation are rather more complicated, as they > +involve a third netdevice (a tunnel netdev operating in metadata mode, such as > +a VxLAN device created with ``ip link add vxlan0 type vxlan external``) and > +require an IP address to be bound to the underlay device (e.g. master PF or port > +representor). TC rules such as:: > + > + tc filter add dev eth1 parent ffff: flower \ > + action tunnel_key set id $VNI src_ip $LOCAL_IP dst_ip $REMOTE_IP \ > + dst_port 4789 \ > + action mirred egress redirect dev vxlan0 > + tc filter add dev vxlan0 parent ffff: flower enc_src_ip $REMOTE_IP \ > + enc_dst_ip $LOCAL_IP enc_key_id $VNI enc_dst_port 4789 \ > + action tunnel_key unset action mirred egress redirect dev eth1 > + Same as above, eth1 name could be more intuitive. --- 8< --- LGTM, only those two small nitpicks. Regards, Marcin
