From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: "Zhang, Qi Z" <qi.z.zhang@intel.com>,
"Zhang, AlvinX" <alvinx.zhang@intel.com>,
"ajit.khaparde@broadcom.com" <ajit.khaparde@broadcom.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v3] ethdev: add IPv4 and L4 checksum RSS offload types
Date: Wed, 7 Jul 2021 12:49:11 +0300 [thread overview]
Message-ID: <238ebfd3-e869-433b-9249-311900ded588@oktetlabs.ru> (raw)
In-Reply-To: <f51d2ffaaeb0425eb9a41da326716c2e@intel.com>
On 7/7/21 6:23 AM, Zhang, Qi Z wrote:
>
>
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Sent: Tuesday, July 6, 2021 4:05 PM
>> To: Zhang, Qi Z <qi.z.zhang@intel.com>; Zhang, AlvinX
>> <alvinx.zhang@intel.com>; ajit.khaparde@broadcom.com
>> Cc: dev@dpdk.org
>> Subject: Re: [PATCH v3] ethdev: add IPv4 and L4 checksum RSS offload types
>>
>> On 7/6/21 10:18 AM, Zhang, Qi Z wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Zhang, AlvinX <alvinx.zhang@intel.com>
>>>> Sent: Tuesday, July 6, 2021 3:06 PM
>>>> To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; Zhang, Qi Z
>>>> <qi.z.zhang@intel.com>; ajit.khaparde@broadcom.com
>>>> Cc: dev@dpdk.org
>>>> Subject: RE: [PATCH v3] ethdev: add IPv4 and L4 checksum RSS offload
>>>> types
>>>>
>>>>>> @@ -537,6 +537,8 @@ struct rte_eth_rss_conf {
>>>>>> #define ETH_RSS_PPPOE (1ULL << 31)
>>>>>> #define ETH_RSS_ECPRI (1ULL << 32)
>>>>>> #define ETH_RSS_MPLS (1ULL << 33)
>>>>>> +#define ETH_RSS_IPV4_CHKSUM (1ULL << 34)
>>>>>> +#define ETH_RSS_L4_CHKSUM (1ULL << 35)
>>>>>
>>>>> What does efine which L4 protocols are supported? How user will know?
>>>>
>>>> I think if we want to support L4 checksum RSS by using below command
>>>> port config all rss (all|default|eth|vlan|...)
>>>>
>>>> We must define TCP/UDP/SCTP checksum RSS separately:
>>>> #define ETH_RSS_TCP_CHKSUM (1ULL << 35)
>>>> #define ETH_RSS_UDP_CHKSUM (1ULL << 36)
>>>> #deifne ETH_RSS_SCTP_CHKSUM (1ULL << 37)
>>>>
>>>> Here 3 bits are occupied, this is not good for there are not many bits
>> available.
>>>>
>>>> If we only want to using it in flows, we only need to define
>>>> ETH_RSS_L4_CHKSUM, because the flow pattern pointed out the L4
>>>> protocol type.
>>>> flow create 0 ingress pattern eth / ipv4 / tcp / end actions rss
>>>> types l4-chksum end queues end / end
>>>
>>> +1, the pattern already give the hint to avoid the ambiguity and I think we
>> already have ETH_RSS_LEVEL to figure out inner or outer.
>>
>> The problem that it may be used in generic RSS flags which has no the context.
>> Also even in the case of flow API context could have no L4 protocol at all.
>
> For generic case, it can simply assume it cover all L4 checksum cases and I'm not sure if any user intend to use it as generic RSS, pmd can simply reject it if it's not necessary to support.
Try to look at it from an application point of view which does
not know any specifics of the driver.
* Get dev_info and see ETH_RSS_L4_CHKSUM, good!, would like to
use it.
* If I try to use it in default RSS config, but the request
fail, it could be very confusing.
* Will it distribute TCP packets? UDP packets? SCTP packets?
Or should I care about RSS for some of them based on other
supported fields? E.g. if SCTP is not supported by the NIC,
I need to install RSS flow rule for the IP protocol to do
RSS based on IPv4/IPv6 addresses. But if SCTP is supported,
I'm happy to use ETH_RSS_L4_CHKSUM for it as well.
> In flow API, if no l4 protocol in pattern , the PMD should return failure (or maybe some default behavior), and I think this is not a new question as it happens all the cases
> e.g.:
> pattern eth / vlan / end action rss type ipv4 .
IMHO, it would be pretty logical to apply RSS to IPv4 packets
only and send everything else to default queue.
>>
>> Is UDP checksum 0 treated as no checksum and go to default queue or treated
>> as a regular checksum with value equal to 0?
>
> I think we can treat it as value 0, as least our hardware behavior like this, is this any issue?
OK, no problem. Just document it.
>>
>> I tend to agree that 3 flags is too much for the feature, but one flag without
>> properly defined meaning is not good as well.
>>
>> I just want rules to be defined and documented.'
>
> Agree, we need more document for this. if you agree above proposal.
>
next prev parent reply other threads:[~2021-07-07 9:49 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 3:12 [dpdk-dev] [PATCH] ethdev: add RSS offload type for L3 checksum Alvin Zhang
2021-06-03 7:14 ` Andrew Rybchenko
2021-06-03 7:28 ` Zhang, AlvinX
2021-06-03 8:03 ` [dpdk-dev] [PATCH v2] ethdev: add IPv4 checksum RSS offload type Alvin Zhang
2021-06-03 8:17 ` Andrew Rybchenko
2021-06-04 2:23 ` Zhang, AlvinX
2021-06-07 18:31 ` Ajit Khaparde
2021-06-15 8:19 ` [dpdk-dev] [PATCH v3] ethdev: add IPv4 and L4 checksum RSS offload types Alvin Zhang
2021-06-15 8:26 ` Jerin Jacob
2021-06-16 15:18 ` Zhang, Qi Z
2021-06-22 8:20 ` Singh, Aman Deep
2021-07-01 14:26 ` Andrew Rybchenko
2021-07-06 6:14 ` Zhang, AlvinX
2021-07-06 7:05 ` Zhang, AlvinX
2021-07-06 7:18 ` Zhang, Qi Z
2021-07-06 8:04 ` Andrew Rybchenko
2021-07-07 3:23 ` Zhang, Qi Z
2021-07-07 9:49 ` Andrew Rybchenko [this message]
2021-07-07 13:00 ` Zhang, Qi Z
2021-07-07 13:10 ` Andrew Rybchenko
2021-07-08 1:07 ` Zhang, Qi Z
2021-07-08 7:45 ` Andrew Rybchenko
2021-07-10 8:38 ` Thomas Monjalon
2021-07-13 1:13 ` [dpdk-dev] [PATCH v4] " Alvin Zhang
2021-07-13 7:54 ` Andrew Rybchenko
2021-07-13 9:38 ` Zhang, AlvinX
2021-07-13 10:24 ` Andrew Rybchenko
2021-07-14 2:38 ` Zhang, AlvinX
2021-08-18 2:32 ` [dpdk-dev] [PATCH v5] " Alvin Zhang
2021-08-29 12:07 ` Zhang, Qi Z
2021-08-31 9:44 ` [dpdk-dev] [PATCH v6] " Alvin Zhang
2021-08-31 9:52 ` [dpdk-dev] [PATCH v7] " Alvin Zhang
2021-09-06 0:28 ` Zhang, Qi Z
2021-09-14 14:00 ` Ferruh Yigit
2021-09-15 1:36 ` Zhang, AlvinX
2021-09-15 5:47 ` [dpdk-dev] [PATCH v8] " Alvin Zhang
2021-09-21 8:26 ` Ferruh Yigit
2021-09-28 13:09 ` Ferruh Yigit
2021-09-29 2:27 ` Zhang, AlvinX
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=238ebfd3-e869-433b-9249-311900ded588@oktetlabs.ru \
--to=andrew.rybchenko@oktetlabs.ru \
--cc=ajit.khaparde@broadcom.com \
--cc=alvinx.zhang@intel.com \
--cc=dev@dpdk.org \
--cc=qi.z.zhang@intel.com \
/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).