On 7/7/21 4:00 PM, Zhang, Qi Z wrote:

quoted

-----Original Message-----
From: Andrew Rybchenko <redacted>
Sent: Wednesday, July 7, 2021 5:49 PM
To: Zhang, Qi Z <redacted>; Zhang, AlvinX
[off-list ref]; ajit.khaparde@broadcom.com
Cc: dev@dpdk.org
Subject: Re: [PATCH v3] ethdev: add IPv4 and L4 checksum RSS offload types

On 7/7/21 6:23 AM, Zhang, Qi Z wrote:

quoted

quoted

-----Original Message-----
From: Andrew Rybchenko <redacted>
Sent: Tuesday, July 6, 2021 4:05 PM
To: Zhang, Qi Z <redacted>; Zhang, AlvinX
[off-list ref]; 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:

quoted

quoted

-----Original Message-----
From: Zhang, AlvinX <redacted>
Sent: Tuesday, July 6, 2021 3:06 PM
To: Andrew Rybchenko <redacted>; Zhang, Qi Z
[off-list ref]; ajit.khaparde@broadcom.com
Cc: dev@dpdk.org
Subject: RE: [PATCH v3] ethdev: add IPv4 and L4 checksum RSS
offload types

quoted

quoted

@@ -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.

quoted

quoted

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.

quoted

quoted

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.

The PMD should not expose it if it don't want to (or not able to) support all l4 checksum from generic RSS configure

Document what is "all L4".

And we should assume this is only apply for generic RSS configure but not for flow API.

I don't think so. IMHO, it should report all RSS capabilities
regardless generic vs flow API RSS action.

It is just RSS capabilities reporting w/o any context.

Because the rte_flow_validate is the recommended method to check if a RSS action is supported in flow API or not.

It could restrict the subset. But superset should be reported
in caps.

quoted

 * 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.

quoted

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.

Yes, this also make sense to me, but I think PMD's flow parser still can have more strict check, as it does not drop any feature that the NIC can support.

quoted

quoted

quoted

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.

quoted

quoted

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.