From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Chaoyong He <chaoyong.he@corigine.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: oss-drivers <oss-drivers@corigine.com>,
Niklas Soderlund <niklas.soderlund@corigine.com>,
Long Wu <long.wu@corigine.com>,
Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v2 1/2] net/nfp: standardize the use of RSS-related codes
Date: Tue, 28 Feb 2023 10:19:02 +0000 [thread overview]
Message-ID: <c4ea1217-b2c4-2aa9-392c-ab5a6d2c25e0@amd.com> (raw)
In-Reply-To: <SJ0PR13MB55458A4B494195FEE2DAE78E9EAC9@SJ0PR13MB5545.namprd13.prod.outlook.com>
On 2/28/2023 8:46 AM, Chaoyong He wrote:
>> On 2/21/2023 3:55 AM, Chaoyong He wrote:
>>> From: Long Wu <long.wu@corigine.com>
>>>
>>> The usage of RTE_ETH_MQ_RX_RSS and RTE_ETH_MQ_RX_RSS_FLAG are
>> mixed in
>>> nfp_net_configure(), use RTE_ETH_MQ_RX_RSS_FLAG uniformly.
>>>
>>> Signed-off-by: Long Wu <long.wu@corigine.com>
>>> Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
>>> Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
>>> ---
>>> drivers/net/nfp/nfp_common.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/nfp/nfp_common.c
>>> b/drivers/net/nfp/nfp_common.c index 907777a9e4..a545a10013 100644
>>> --- a/drivers/net/nfp/nfp_common.c
>>> +++ b/drivers/net/nfp/nfp_common.c
>>> @@ -171,7 +171,7 @@ nfp_net_configure(struct rte_eth_dev *dev)
>>> }
>>>
>>> /* Checking RX mode */
>>> - if (rxmode->mq_mode & RTE_ETH_MQ_RX_RSS &&
>>> + if (rxmode->mq_mode & RTE_ETH_MQ_RX_RSS_FLAG &&
>>> !(hw->cap & NFP_NET_CFG_CTRL_RSS_ANY)) {
>>> PMD_INIT_LOG(INFO, "RSS not supported");
>>> return -EINVAL;
>>
>> They are same values, but when used as a mask, flag one can be more
>> proper.
>>
>> BUT,
>> Not sure how correct to '&' an enum element, enums supposed to be
>> abstraction on underneath values, right?
>> For this case user should know/care enum values which is wrong, perhaps to
>> OR flags to make enum elements was a mistake on our end.
>>
>> Anyway, with above usage all enum elements that has RSS_FLAG is taken
>> into account, like 'RTE_ETH_MQ_RX_VMDQ_RSS' (RSS mode with VMDq),
>> are you sure that is the intention, is there a chance you meant:
>>
>> if (rxmode->mq_mode == RTE_ETH_MQ_RX_RSS && ...)
>>
>>
>> btw, what if mq_mode is 'RTE_ETH_MQ_RX_VMDQ_DCB', is it supported?
>>
> For now, we don't support 'RTE_ETH_MQ_RX_VMDQ_DCB'.
>
My point was it is not checked in the driver, and that is the case for
most of the drivers, which means if user requests it, it will be
silently ignored, and if application depends on this feature this will
break the app.
So 'mq_mode' config option is not honored properly, for majority of the
cases all user/driver interested in is RSS, only a few drivers that
support other multi queue modes handles other cases.
We may improve this bit better in the ethdev layer, like providing a
mq_mode capability, etc...
>>
>> I just recognized there are various similar usage in drivers, and most of them
>> comes from same commit [1], we can discuss and fix that separately.
>>
> I saw you plan drop the RFC commit [1], so what we should do about this patch?
> 1. Keep our modify.
> 2. Follow your modify.
> 3. We just drop this commit. (your patch series will correct it anyway).
> Please give me an advice to guide my next move, thanks.
>
Keep your modify,
when we continue to '&' 'rxmode->mq_mode' value, should use _FLAG as you
are updating in your patch.
>> [1]
>> 73fb89dd6a00 ("drivers/net: fix RSS hash offload flag if no RSS")
next prev parent reply other threads:[~2023-02-28 10:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-21 3:10 [PATCH 0/2] configure RSS and handle metadata correctly Chaoyong He
2023-02-21 3:10 ` [PATCH 1/2] net/nfp: standardize the use of RSS-related codes Chaoyong He
2023-02-21 3:10 ` [PATCH 2/2] net/nfp: modify RSS's processing logic Chaoyong He
2023-02-21 3:29 ` [PATCH v2 0/2] configure RSS and handle metadata correctly Chaoyong He
2023-02-21 3:29 ` [PATCH v2 1/2] net/nfp: standardize the use of RSS-related codes Chaoyong He
2023-02-21 3:29 ` [PATCH v2 2/2] net/nfp: modify RSS's processing logic Chaoyong He
2023-02-21 3:55 ` [PATCH v2 0/2] configure RSS and handle metadata correctly Chaoyong He
2023-02-21 3:55 ` [PATCH v2 1/2] net/nfp: standardize the use of RSS-related codes Chaoyong He
2023-02-23 15:13 ` Ferruh Yigit
2023-02-28 8:46 ` Chaoyong He
2023-02-28 10:19 ` Ferruh Yigit [this message]
2023-02-21 3:55 ` [PATCH v2 2/2] net/nfp: modify RSS's processing logic Chaoyong He
2023-02-28 17:24 ` [PATCH v2 0/2] configure RSS and handle metadata correctly 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=c4ea1217-b2c4-2aa9-392c-ab5a6d2c25e0@amd.com \
--to=ferruh.yigit@amd.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=chaoyong.he@corigine.com \
--cc=dev@dpdk.org \
--cc=long.wu@corigine.com \
--cc=niklas.soderlund@corigine.com \
--cc=oss-drivers@corigine.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).