[ovs-dev] [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow

Finn Christensen fc at napatech.com
Wed Sep 27 10:41:32 UTC 2017


    -----Original Message-----
    From: Yuanhan Liu [mailto:yliu at fridaylinux.org]
    Sent: 27. september 2017 11:47
    To: Finn Christensen <fc at napatech.com>
    Cc: Darrell Ball <dball at vmware.com>; dev at openvswitch.org; Chandran
    Sugesh <sugesh.chandran at intel.com>; Simon Horman
    <simon.horman at netronome.com>
    Subject: Re: [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow
    
    On Wed, Sep 27, 2017 at 09:12:49AM +0000, Finn Christensen wrote:
    >
    >     [Darrell] It looks fine; of course, if we could drop dependencies on cap
    >     probe, it would be ideal (.
    >
    >
    > [Finn]
    > From a Napatech point of view, we would definitely want to use the
    > RTE_FLOW_ACTION_TYPE_RSS if it were implement. It definitely makes
    > good sense to me. I have 2 reasons for this:
    > 1. It would fit nicely into the way Napatech does flow programming in
    > nic 2. We would be fully RSS controlled through OVS Furthermore,
    > Future RSS splitting on a per megaflow basis will be possible.
    > IMO the "pure_mark_cap_probed" function is a temp work-around to
    make it work.
    > The RSS seems to be a solution to the queue problem.
    
    Finn, that's really good to know! I do agree without this probe, it makes the
    code simpler and cleaner.
    
    Few questions though. Have Napatech already implemented rss action? If
    not, what's the plan? 

[Finn]
Our nic handles rss on a per flow basis, but we have not yet used rte rss action 
for OVS. In OVS we simply handles RSS config outside it.
The full control of rss through OVS is better though.

    And are you okay with following code?
    
    	add_mark_action();
    	add_rss_action_unconditionally();
    
    	flow = rte_create_flow(...);
    	if (!flow)
    		return -1;
    
    That is, no probes, no feedbacks. If it failed, it just failed (flow offload then
    is just skipped).
    
[Finn]
Yes, we can easily make this work. Good suggestion!


    But I do think some feedbacks are necessary. If we know the rte_flow cap
    in the begnning, we could simply disable the flow offload for a specific port
    if we know it doesn't have offload ability. This would avoid the repeat
    effort of trying to do hw offload completely.
    
[Finn]
This seems to be a good idea.


    	--yliu


More information about the dev mailing list