-----Original Message----- From: Finn Christensen <[email protected]> Date: Tuesday, September 5, 2017 at 11:53 PM To: Harish Patil <[email protected]>, Yuanhan Liu <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: RE: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow
> >-----Original Message----- >From: Patil, Harish [mailto:[email protected]] >Sent: 6. september 2017 08:34 >To: Yuanhan Liu <[email protected]>; [email protected] >Cc: Finn Christensen <[email protected]>; [email protected] >Subject: Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow > > > >-----Original Message----- >From: <[email protected]> on behalf of Yuanhan Liu ><[email protected]> >Date: Tuesday, September 5, 2017 at 2:22 AM >To: "[email protected]" <[email protected]> >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. [Harish] Thanks Finn for confirming the behavior. >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. [Harish I did not fully understand this part. Can you pls elaborate and possibly with an example? [Harish] I have another question: There was a patch series (11/11) submitted regarding offloading dpcls from Shachar Beiser. [ovs-dev] [PATCH 00/11] Data Path Classifier Offloading .. .. [ovs-dev] [PATCH 11/11] ovs/dp-cls: inserting rule to HW from offloading thread context. This does not use RTE_FLOW filtering framework. I don’t know status of this patch series. But this is very similar to what is being achieved with your current patch series using RTE_FLOW. Which one will be accepted in the end in the mainline OVS branch? Thanks, Harish > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
