> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Monday, November 15, 2021 5:09 PM
> Subject: Re: [dpdk-dev] [PATCH] ethdev: fine tune error reporting in pick
> transfer proxy API
>
> 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.rybche...@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.
>
+1
Ori
