On 8/22/17, 11:24 PM, "Yuanhan Liu" <y...@fridaylinux.org> wrote:
    
        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 resues 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
        almost 80% performance boost. For PHY-vhost forwarding, I got about 50%
        performance boost.
        
        
        Though that being said, this patchset still has issues unresolved. The
        major issue is that maybe most NIC (for instance, Mellanox and Intel)
        can not support a pure MARK action. It has to be used together with a
        QUEUE action, which in turn needs a queue index. That comes to the 
issue:
        the queue index is not given in the flow context. To make it work, patch
        5 just set the queue index to 0, which is obviously wrong. One possible
        solution is to record the rxq and pass it down to the flow creation
        stage. It would be much better, but it's still far away from being 
perfect.
        Because it might have changed the steering rules stealthily, which may
        break the default RSS setup by OVS-DPDK.

If this cannot be solved by removing this restriction, I guess another 
alternative is to actively
manage flow-queue associations.

        
        The reason I still want to send it out is to get more comments/thoughts
        from community on this whole patchset. Meanwhile, I will try to resolve
        the QUEUE action issue.
        
        Note that it's disabled by default, which can be enabled by:
        
            $ ovs-vsctl set Open_vSwitch . other_config:hw-offload=true

Maybe per in-port configuration would alleviate the issue to a certain degree.

        
        Thanks.
        
            --yliu
        
        ---
        Finn Christensen (3):
          netdev-dpdk: implement flow put with rte flow
          netdev-dpdk: retry with queue action
          netdev-dpdk: set FDIR config
        
        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   |  13 ++
         lib/dpif-netdev.c | 105 +++++++++++
         lib/netdev-dpdk.c | 511 
+++++++++++++++++++++++++++++++++++++++++++++++++++++-
         lib/netdev.h      |   6 +
         4 files changed, 634 insertions(+), 1 deletion(-)
        
        -- 
        2.7.4
        
        
    
    

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to