Re: [dpdk-dev] [PATCH] ethdev: fine tune error reporting in pick transfer proxy API

[Thomas Monjalon <thomas@monjalon.net>]

15/11/2021 15:15, Ivan Malov:
> On Wed, 10 Nov 2021, Ferruh Yigit wrote:
> 
> > On 11/2/2021 5:04 PM, David Marchand wrote:
> >> On Tue, Nov 2, 2021 at 4:59 PM Andrew Rybchenko
> >> <andrew.rybchenko@oktetlabs.ru> wrote:
> >>>>> IMHO, spamming of testpmd logs in described case should be fixed
> >>>>> in testpmd itself to avoid logs in the case of ENOTSUP. That's it.
> >>>> 
> >>>> I think we should not call this API in testpmd
> >>>> if not doing rte_flow transfer rule.
> >>>> 
> >>> 
> >>> Since testpmd does not pursue top flow insertion rate etc,
> >>> I tend to agree. For debugging purposes (testpmd main goal)
> >>> the best way is to pick proxy just before usage without any
> >>> caching etc.
> >> 
> >> +1.
> >> 
> >
> > +1 to not call this API when not doing rte_flow transfer rule,
> > and get rid of this testpmd logs..
> >
> 
> Hi all,
> 
> I apologise for the delay. These arguments make sense. Thanks.
> 
> However, the idea to hide the proxy port request inside flow
> command handlers might be wrong in fact. It is too much code
> churn. And it is easy to overlook this part when adding new
> indirect action handlers that are also suited for use in
> transfer flows. To code maintainers, it is very vague.
> 
> Now you mention it, testpmd is indeed scenario-dependent. Its
> workings should be explicitly controllable by the user. That
> means, the proxy thing should be exposed via an explicit
> command: "show port <port_id> flow_transfer_proxy".
> 
> As testpmd is a debug tool, it should simply do what the user
> says. Suppose, the user wants to create transfer flows. They
> realise that doing so may require proxy. Hence, they request
> the proxy and then use the resulting port ID in all commands
> which have something to do with transfer flows. Very robust.
> 
> And, of course, this way, the request is done only when the
> user needs it, and spamming the log is also gone. Let the
> user query the proxy themselves, and things become simple.
> 
> Please vote in favor of my motion. It will not break anything.
> Right now, in this release cycle, nobody supports the proxy
> thing, so the existing flow use cases should work as normal.
> 
> Opinions are welcome.

I'm fine with this proposal.