[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