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

Darrell Ball dball at vmware.com
Wed Sep 27 03:54:02 UTC 2017



On 9/26/17, 8:27 PM, "Yuanhan Liu" <yliu at fridaylinux.org> wrote:

    On Wed, Sep 27, 2017 at 03:13:33AM +0000, Darrell Ball wrote:
    > 
    > 
    > On 9/26/17, 6:25 PM, "Yuanhan Liu" <yliu at fridaylinux.org> wrote:
    > 
    >     On Tue, Sep 26, 2017 at 09:58:16PM +0000, Darrell Ball wrote:
    >     >     The second major change is there is a thread introduced to do the real
    >     >     flow offload. This is for diminishing the overhead by hw flow offload
    >     >     installation/deletion at data path. See patch 9 for more detailed info.
    >     > 
    >     > [Darrell] There might be other options to handle this such as dividing time
    >     > to HWOL in a given PMD. 
    >     > Another option to have PMD isolation.
    >     
    >     Good to know, though I'm not sure I understand it so far. But it can be
    >     discussed later. That's also the reason I put it in the last patch, so
    >     that we could easily turn it to another solution, or even simpler (just
    >     remove it).
    >     
    >     >     In the last discussion, RSS action was suggested to use to get rid of
    >     >     the QUEUE action workaround. Unfortunately, it didn't work. The flow
    >     >     creation failed with MLX5 PMD driver, and that's the only driver in
    >     >     DPDK that supports RSS action so far.
    >     > 
    >     > 
    >     > [Darrell] 
    >     > I wonder if we should take a pause before jumping into the next version of the code.
    >     
    >     I have no objections.
    >     
    >     > If workarounds are required in OVS code, then so be it as long as they are not
    >     > overly disruptive to the existing code and hard to maintain.
    >     > In the case of RTE_FLOW_ACTION_TYPE_RSS, we might have a reasonable option
    >     > to avoid some unpleasant OVS workarounds.
    >     > This would make a significant difference in the code paths, if we supported it, so
    >     > we need to be sure as early as possible.
    >     
    >     I agree.
    >     
    >     > The support needed would be in some drivers and seems reasonably doable. 
    >     > Moreover, this was discussed in the last dpdk meeting and the support was
    >     > indicated as existing?, although I only verified the MLX code, myself.
    >     
    >     From the code point of view, yes, the code was there months ago.
    >     
    >     > I had seen the MLX code supporting _RSS action and there are some checks for
    >     > supported cases; when you say “it didn't work”, what was the issue ?
    >     
    >     I actually have met the error months ago, I even debugged it. IIRC,
    >     the error is from libibverbs, when trying to create the hw flow. I
    >     think I need double-confirm it with our colleague who developed this
    >     feature.
    >     
    >     > Let us have a discussion also about the Intel nic side and the Napatech side.
    >     
    >     I think it's not necessary for Napatech, because they can support
    >     MARK only action.
    >     
    > It is not necessary for Napatech; however to avoid the need to detect the Napatech
    > special (good) case, ‘ideally’ we do the exact same programming even in Napatech case.
    
    Will following look okay to you (assuming we have the probe ability and DPDK
    has some basic capability feedback)?
    
    	if (!pure_mark_cap_probed) {
    		if (dpdk_rte_flow_has_rss_action_support) {
    			append_rss_action();
    		} else {
    			fail and return;
    		}
    	}
    
    	/* create flow once, with no retries, if fails, let it fail */
    	flow = rte_flow_create(...);
    
    I assume that's how the code looks like finally. What do you think?


[Darrell] It looks fine; of course, if we could drop dependencies on cap probe, it would be ideal (.              

    
    	--yliu
    
    >     For Intel, yes, I think Intel folks could give some comments here.
    >     
    >     > It seems reasonable to ask where the disconnect is and whether this support
    >     > can be added and then make a decision based on the answers. 
    >     
    >     No objections.
    >     
    >     	--yliu
    >     
    > 
    



More information about the dev mailing list