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.
