| Message ID | 20201214022001.84273-1-xiangxia.m.yue@gmail.com |
|---|---|
| Headers | show |
| Series | Support Flow Bifurcation | expand |
On Mon, Dec 14, 2020 at 10:19:57AM +0800, xiangxia.m.yue@gmail.com wrote: > From: Tonghao Zhang <xiangxia.m.yue@gmail.com> > > Flow Bifurcation is a mechanism which uses hardware capable > Ethernet devices to split traffic between Linux user space > and kernel space. Since it is a hardware assisted feature > this approach can provide line rate processing capability. > Other than KNI, the software is just required to enable device > configuration, there is no need to take care of the packet > movement during the traffic split. This can yield better > performance with less CPU overhead. > > The Flow Bifurcation splits the incoming data traffic to > user space applications (such as DPDK applications) and/or > kernel space programs (such as the Linux kernel stack). > It can direct some traffic, for example data plane traffic, > to DPDK, while directing some other traffic, for example > control plane traffic, to the traditional Linux networking stack. > > There are a number of technical options to achieve this. > A typical example is to combine the technology of SR-IOV and > packet classification filtering. > > Open vSwitch used in this case: > 1: > > +----------+ +----------+ > | kernel | | ovs-dpdk | (no address assigned) > +----+-----+ +----+-----+ > ^ ^ > | PF(1.1.1.1/24) |VF0 > | | > +----+------------------+-----+ > | SRIOV NIC | > +-----------------------------+ > > In this case, we can use patch 3, 4 to learn neigh entries(1.1.1.0/24) > from linux kernel, to install routes: > $ ovs-vsctl --no-wait set Open_vSwitch . other_config:tnl-neigh-event-enabled=true > $ ovs-appctl ovs/route/add 1.1.1.1/32 br-int src_addr=1.1.1.1 > $ ovs-appctl ovs/route/add 1.1.1.0/24 br-int src_addr=1.1.1.1 > $ ovs-appctl ovs/route/add 0.0.0.0/0 br-int src_addr=1.1.1.1 > > 2: > +----------+ +----------+ > | kernel | | ovs-dpdk | (no address assigned) > +----+-----+ +----+-----+ > ^ ^ > | PF(1.1.1.1/24) | PF > | | > +----+------------------+-----+ > | SRIOV NIC | > +-----------------------------+ > > In sriov nic, we can add flows which matching tunnel packets > to ovs-dpdk, and others packets to linux kenrel (patch 1, 2). > When sending tunnel packets, ovs can use neigh entries learned > from system. > > More details: > http://doc.dpdk.org/guides-20.11/howto/flow_bifurcation.html > https://doc.dpdk.org/guides/prog_guide/rte_flow.html # 12.4. Flow isolated mode > > Tonghao Zhang (4): > netdev-dpdk: Allow to config isolate offload mode. > dpctl: Add --consistent option. > tnl-neigh-cache: Allow openvswitch learning neigh entries. > ovs-router: Allow openvswitch installing fake routes. Hi Tonghao Zhang, This patch-set appears to have gone stale in patchwork, for one reason or another. If it is still relevant then I think it needs to be revisited, by being reposted after appropriate preparation. As such I'm marking this patch-set as "Deferred" in patchwork. No action is required unless there is a desire to revisit this patch.
From: Tonghao Zhang <xiangxia.m.yue@gmail.com> Flow Bifurcation is a mechanism which uses hardware capable Ethernet devices to split traffic between Linux user space and kernel space. Since it is a hardware assisted feature this approach can provide line rate processing capability. Other than KNI, the software is just required to enable device configuration, there is no need to take care of the packet movement during the traffic split. This can yield better performance with less CPU overhead. The Flow Bifurcation splits the incoming data traffic to user space applications (such as DPDK applications) and/or kernel space programs (such as the Linux kernel stack). It can direct some traffic, for example data plane traffic, to DPDK, while directing some other traffic, for example control plane traffic, to the traditional Linux networking stack. There are a number of technical options to achieve this. A typical example is to combine the technology of SR-IOV and packet classification filtering. Open vSwitch used in this case: 1: +----------+ +----------+ | kernel | | ovs-dpdk | (no address assigned) +----+-----+ +----+-----+ ^ ^ | PF(1.1.1.1/24) |VF0 | | +----+------------------+-----+ | SRIOV NIC | +-----------------------------+ In this case, we can use patch 3, 4 to learn neigh entries(1.1.1.0/24) from linux kernel, to install routes: $ ovs-vsctl --no-wait set Open_vSwitch . other_config:tnl-neigh-event-enabled=true $ ovs-appctl ovs/route/add 1.1.1.1/32 br-int src_addr=1.1.1.1 $ ovs-appctl ovs/route/add 1.1.1.0/24 br-int src_addr=1.1.1.1 $ ovs-appctl ovs/route/add 0.0.0.0/0 br-int src_addr=1.1.1.1 2: +----------+ +----------+ | kernel | | ovs-dpdk | (no address assigned) +----+-----+ +----+-----+ ^ ^ | PF(1.1.1.1/24) | PF | | +----+------------------+-----+ | SRIOV NIC | +-----------------------------+ In sriov nic, we can add flows which matching tunnel packets to ovs-dpdk, and others packets to linux kenrel (patch 1, 2). When sending tunnel packets, ovs can use neigh entries learned from system. More details: http://doc.dpdk.org/guides-20.11/howto/flow_bifurcation.html https://doc.dpdk.org/guides/prog_guide/rte_flow.html # 12.4. Flow isolated mode Tonghao Zhang (4): netdev-dpdk: Allow to config isolate offload mode. dpctl: Add --consistent option. tnl-neigh-cache: Allow openvswitch learning neigh entries. ovs-router: Allow openvswitch installing fake routes. lib/dpctl.c | 24 ++++ lib/dpctl.h | 3 + lib/dpif-netdev.c | 1 + lib/netdev-dpdk.c | 23 ++++ lib/odp-util.c | 11 ++ lib/odp-util.h | 1 + lib/ovs-router.c | 121 +++++++++------- lib/tnl-neigh-cache.c | 312 ++++++++++++++++++++++++++++++++++++++++-- lib/tnl-neigh-cache.h | 2 + lib/uuid.h | 3 + ofproto/ofproto-dpif-upcall.c | 7 + vswitchd/bridge.c | 2 + vswitchd/vswitch.xml | 17 +++ 13 files changed, 468 insertions(+), 59 deletions(-)