-----Original Message----- From: Patil, Harish [mailto:harish.pa...@cavium.com] Sent: 6. september 2017 08:34 To: Yuanhan Liu <y...@fridaylinux.org>; d...@openvswitch.org Cc: Finn Christensen <f...@napatech.com>; db...@vmware.com Subject: Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow
-----Original Message----- From: <ovs-dev-boun...@openvswitch.org> on behalf of Yuanhan Liu <y...@fridaylinux.org> Date: Tuesday, September 5, 2017 at 2:22 AM To: "d...@openvswitch.org" <d...@openvswitch.org> Subject: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow >Hi, > >Here is a joint work from Mellanox and Napatech, to enable the flow hw >offload with the DPDK generic flow interface (rte_flow). > >The basic idea is to associate the flow with a mark id (a unit32_t >number). >Later, we then get the flow directly from the mark id, bypassing the >heavy emc processing, including miniflow_extract. > >The association is done with CMAP in patch 1. It also reuses the flow >APIs introduced while adding the tc offloads. The emc bypassing is done >in patch 2. The flow offload is done in patch 4, which mainly does two >things: > >- translate the ovs match to DPDK rte flow patterns >- bind those patterns with a MARK action. > >Afterwards, the NIC will set the mark id in every pkt's mbuf when it >matches the flow. That's basically how we could get the flow directly >from the received mbuf. > >While testing with PHY-PHY forwarding with one core and one queue, I >got about 54% performance boost. For PHY-vhost forwarding, I got about >41% performance boost. The reason it's lower than v1 is I added the >logic to get the correct tcp_flags, which examines all packets recieved. > >The major issue mentioned in last version is also workarounded: the >queue index is never set to 0 blindly anymore, but set to the rxq that >first receives the upcall pkt. > >Note that it's disabled by default, which can be enabled by: > > $ ovs-vsctl set Open_vSwitch . other_config:hw-offload=true > > >v2: - workaround the queue action issue > - fixed the tcp_flags being skipped issue, which also fixed the > build warnings > - fixed l2 patterns for Intel nic > - Converted some macros to functions > - did not hardcode the max number of flow/action > - rebased on top of the lastest code > >Thanks. > > --yliu > > >--- >Finn Christensen (3): > netdev-dpdk: implement flow put with rte flow > netdev-dpdk: retry with queue action > netdev-dpdk: set FDIR config > >Shachar Beiser (1): > dpif-netdev: record rx queue id for the upcall > >Yuanhan Liu (4): > dpif-netdev: associate flow with a mark id > dpif-netdev: retrieve flow directly from the flow mark > netdev-dpdk: convert ufid to dpdk flow > netdev-dpdk: remove offloaded flow on deletion > > lib/dp-packet.h | 14 ++ > lib/dpif-netdev.c | 132 +++++++++++-- > lib/flow.c | 78 ++++++++ > lib/flow.h | 1 + > lib/netdev-dpdk.c | 574 >+++++++++++++++++++++++++++++++++++++++++++++++++++++- > lib/netdev.c | 1 + > lib/netdev.h | 7 + > 7 files changed, 795 insertions(+), 12 deletions(-) > >-- >2.7.4 > Hi all, Can you please confirm that you are supporting offloading of both the EMC flows and DPCLs (megaflows) here, i.e. OVS would skip hash table lookups in both the cases if UFID is provided in the MBUF. Assuming that is correct, when a match is found in dpcls, does OVS insert that new flow back into the EMC cache? Thanks, Harish [Finn] Yes, you are correct. Once the megaflow is offloaded into NIC, using the flow UFID, the EMC and megaflow cache (dpcls) is skipped when a UFID is received in mbuf. When receiving these pre-classified packets the EMC is not needed. However, the initial packet creating the megaflow (and then also creates the NIC rte flow), will be inserted into EMC. But, new flows that would use the same megaflow, but would create a different EMC entry, will not be inserted/created in EMC when offloaded by NIC. > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
