[ovs-dev] [PATCH v2 6/8] netdev-dpdk: retry with queue action

Simon Horman simon.horman at netronome.com
Wed Sep 13 09:57:31 UTC 2017


On Tue, Sep 12, 2017 at 08:36:19AM +0000, Darrell Ball wrote:
> 
> On 9/10/17, 11:14 PM, "ovs-dev-bounces at openvswitch.org on behalf of Yuanhan Liu" <ovs-dev-bounces at openvswitch.org on behalf of yliu at fridaylinux.org> wrote:
> 
>     On Fri, Sep 08, 2017 at 06:48:50PM +0200, Simon Horman wrote:
>     > On Tue, Sep 05, 2017 at 05:22:59PM +0800, Yuanhan Liu wrote:
>     > > From: Finn Christensen <fc at napatech.com>
>     > > 
>     > > AFAIK, most (if not all) NICs (including Mellanox and Intel) do not
>     > > support a pure MARK action.  It's required to be used together with
>     > > some other actions, like QUEUE.
>     > > 
>     > > To workaround it, retry with a queue action when first try failed.
>     > > 
>     > > Moreover, some Intel's NIC (say XL710) needs the QUEUE action set
>     > > before the MARK action.
>     > > 
>     > > Co-authored-by: Yuanhan Liu <yliu at fridaylinux.org>
>     > > Signed-off-by: Finn Christensen <fc at napatech.com>
>     > > Signed-off-by: Yuanhan Liu <yliu at fridaylinux.org>
>     > 
>     > This feels a bit like the tail wagging the dog.
>     > Is this the lowest level at which it makes sense to implement
>     > this logic?
>     > 
>     > If so then I wonder if some sort of probing would be in order
>     > to avoid the cost of trying to add the flow twice to hardware
>     > where the queue is required.
>     
>     Do you mean something like rte_flow capability query, like whether
>     a queue action is needed for a mark action? If so, yes, I do think
>     we miss an interface like this.
>     
>     Note that even in this solution, the flow won't be created twice
>     to the hardware, because the first try would be failed.
> 
> [Darrell]
> 
>               Having an api to quey capability and avoid the first try to HW would be nice, but there are dependencies
>                on RTE, drivers etc and I don’t know definitive the api would be.
> 
>              Also, as nics are added this capability needs to be done and state needs to be kept in all cases.
> 
>            It is an enhancement and if done should be reliable.

Agreed. Though I was more thinking of probing the hardware rather than
having a capability API - I expect this would remove several of the
dependencies you describe above.

Assuming no such enhancement is appropriate at this time I would
still like to ask if this is the best place for this hardware-specific code?

>            A separate comment is we need to document which nics need the queue action.
> 
>          Also, I think we should check errno in the present code.


More information about the dev mailing list