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.
--
Ivan M.
