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

[Darrell Ball]

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.


    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