DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ivan Malov <Ivan.Malov@oktetlabs.ru>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, David Marchand <david.marchand@redhat.com>,
	Ferruh Yigit <ferruh.yigit@intel.com>, Ori Kam <orika@nvidia.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Subject: Re: [dpdk-dev] [PATCH] ethdev: fine tune error reporting in pick transfer proxy API
Date: Thu, 28 Oct 2021 19:24:20 +0300	[thread overview]
Message-ID: <43fd9b2e-5c2e-d464-5b24-88a2d8da0e1e@oktetlabs.ru> (raw)
In-Reply-To: <5927197.slJBfLvSNU@thomas>

Good day to you, Thomas.

On 27/10/2021 13:57, Thomas Monjalon wrote:
> 27/10/2021 11:55, Ivan Malov:
>> Hi Thomas,
>>
>> On 27/10/2021 12:46, Thomas Monjalon wrote:
>>> 27/10/2021 11:00, Ivan Malov:
>>>> There are PMDs which do not support flow offloads at all.
>>>> In such cases, the API in question returns ENOTSUP. This
>>>> is too loud. Restructure the code to avoid spamming logs.
>>>>
>>>> Fixes: 1179f05cc9a0 ("ethdev: query proxy port to manage transfer flows")
>>>>
>>>> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
>>>> ---
>>>> --- a/lib/ethdev/rte_flow.c
>>>> +++ b/lib/ethdev/rte_flow.c
>>>> @@ -1335,10 +1335,7 @@ rte_flow_pick_transfer_proxy(uint16_t port_id, uint16_t *proxy_port_id,
>>>>    	const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
>>>>    	struct rte_eth_dev *dev;
>>>>    
>>>> -	if (unlikely(ops == NULL))
>>>> -		return -rte_errno;
>>>> -
>>>> -	if (ops->pick_transfer_proxy == NULL) {
>>>> +	if (ops == NULL || ops->pick_transfer_proxy == NULL) {
>>>>    		*proxy_port_id = port_id;
>>>>    		return 0;
>>>>    	}
>>>
>>> I prefer this logic.
>>
>> Thank you.
>>
>>> You could add a comment to say that the current port is the default.
>>
>> As far as I remember, the comment ("note") is already in place (rte_flow.h).
> 
> I meant adding a comment in the implementation above.

Technically, I don't object adding it. But isn't the
idea expressed clear enough by the code itself?

> 
>>> There is also this logic in testpmd:
>>>
>>>       port->flow_transfer_proxy = port_id;
>>>       if (!is_proc_primary())
>>>           return;
>>>
>>> Could we manage secondary process case inside the API?
>>
>> Shouldn't we manage secondary process in *all* flow APIs then?
> 
> Hmm, yes logically we should not care about secondary process at all in rte_flow.
> OK to leave it as is.

Thank you.

> 
>>> One more comment, for testpmd,
>>> we are calling rte_flow_pick_transfer_proxy even if we do not config any transfer flow.
>>> It is called always in init_config_port_offloads().
>>> It looks wrong. Can we call it only when needed?
>>
>> In which way does it look wrong? Does it inflict error(s), malfunction,
>> performance drops? Please elaborate.
> 
> It is testing a function that we don't intend to test in a basic use case.

Not really. The original idea is to invoke this API only once, on
port (re-)plug and remember the proxy port ID to be used on each
flow create invocation. Theoretically, when the new asynchronous
flow API arrives, this approach will be even more to the point.

> A driver can introduce a malfunction with this API while
> we don't use rte_flow at all in the test scenario.

Fat chance. Even if that happens, it will draw attention. It is
the duty of test-pmd to detect such malfunction after all. If
the current code comes across a bug in some driver, it should
be good, shouldn't it? Test coverage gets extended, right?

-- 
Ivan M

  reply	other threads:[~2021-10-28 16:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27  9:00 Ivan Malov
2021-10-27  9:46 ` Thomas Monjalon
2021-10-27  9:55   ` Ivan Malov
2021-10-27 10:57     ` Thomas Monjalon
2021-10-28 16:24       ` Ivan Malov [this message]
2021-10-29  8:11         ` Thomas Monjalon
2021-11-01  9:41 ` Andrew Rybchenko
2021-11-02 15:45   ` Thomas Monjalon
2021-11-02 15:58     ` Andrew Rybchenko
2021-11-02 17:04       ` David Marchand
2021-11-10 14:21         ` Ferruh Yigit
2021-11-15 14:15           ` Ivan Malov
2021-11-15 15:09             ` Thomas Monjalon
2021-11-15 15:30               ` Ori Kam
2021-11-03 14:38     ` Ori Kam
2021-11-16 15:38 ` [PATCH] app/testpmd: fix flow transfer proxy port handling Ivan Malov
2021-11-16 19:23   ` Ori Kam
2021-11-17  7:41   ` Slava Ovsiienko
2021-11-17 10:54     ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43fd9b2e-5c2e-d464-5b24-88a2d8da0e1e@oktetlabs.ru \
    --to=ivan.malov@oktetlabs.ru \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=orika@nvidia.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).