DPDK usage discussions
 help / color / mirror / Atom feed
* net/mlx5 RTE_ETH_RSS_SCTP support
@ 2024-08-01 13:01 Igor Gutorov
  2024-09-29  9:18 ` Gregory Etelson
  0 siblings, 1 reply; 4+ messages in thread
From: Igor Gutorov @ 2024-08-01 13:01 UTC (permalink / raw)
  To: users; +Cc: dsosnowski, viacheslavo, bingz, orika, suanmingm, matan

Hello,

I'm wondering about SCTP RSS support in MLX5 NICs.

testpmd does not show ipv4-sctp or ipv6-sctp as supported:

testpmd> show port info 0
Supported RSS offload flow types:
 ipv4  ipv4-frag  ipv4-tcp  ipv4-udp  ipv4-other  ipv6
 ipv6-frag  ipv6-tcp  ipv6-udp  ipv6-other  ipv6-ex
 ipv6-tcp-ex  ipv6-udp-ex  esp  l4-dst-only  l4-src-only
 l3-dst-only  l3-src-only

Is this a hardware, firmware, or PMD limitation?

Thanks!

Sincerely,
Igor Gutorov.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* net/mlx5 RTE_ETH_RSS_SCTP support
  2024-08-01 13:01 net/mlx5 RTE_ETH_RSS_SCTP support Igor Gutorov
@ 2024-09-29  9:18 ` Gregory Etelson
  2024-09-30 23:50   ` Igor Gutorov
  0 siblings, 1 reply; 4+ messages in thread
From: Gregory Etelson @ 2024-09-29  9:18 UTC (permalink / raw)
  To: igootorov
  Cc: getelson, bingz, dsosnowski, matan, orika, suanmingm, users, viacheslavo

Hello,

> I'm wondering about SCTP RSS support in MLX5 NICs.
> testpmd does not show ipv4-sctp or ipv6-sctp as supported

MLX5 hardware does not offload SCTP RSS.

Regards,
Gregory

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: net/mlx5 RTE_ETH_RSS_SCTP support
  2024-09-29  9:18 ` Gregory Etelson
@ 2024-09-30 23:50   ` Igor Gutorov
  2024-10-01 13:58     ` Gregory Etelson
  0 siblings, 1 reply; 4+ messages in thread
From: Igor Gutorov @ 2024-09-30 23:50 UTC (permalink / raw)
  To: Gregory Etelson
  Cc: bingz, dsosnowski, matan, orika, suanmingm, users, viacheslavo

Hello,

On Sun, Sep 29, 2024 at 12:18 PM Gregory Etelson <getelson@nvidia.com> wrote:
>
> Hello,
>
> > I'm wondering about SCTP RSS support in MLX5 NICs.
> > testpmd does not show ipv4-sctp or ipv6-sctp as supported
>
> MLX5 hardware does not offload SCTP RSS.
>
> Regards,
> Gregory

Thank you for the response!
That is unfortunate.

Do you think it is possible to achieve something similar to RSS
offload using the flow engine?

Let me share a bit more about what I'm trying to do. I have a DPDK
application that I want to add SCTP deduplication to.
One of the challenges is that duplicated packets might have different
IP addresses, but identical SCTP layers, causing these duplicates to
be steered to different Rx queues (and hence different threads) by the
default IP RSS offload.

So, I thought I had few options here:
- disable RSS (not really an option, unfortunately)
- software based (computing RSS hash in software and software steering
the packets, or using global lock-free deduplication tables, or so on)
- hardware based, where RSS would be performed on SCTP ports only,
causing the duplicated packets to be steered to the same Rx queues.
This would allow the usage of per thread deduplication tables and
eliminate some overhead from the software based approach.

Since SCTP RSS offload is not supported, do you think it is possible
to "bypass" this limitation? One idea I had is something along these
lines:
- Build an eth / ipv4  pattern. Where the IP item has the proto_id
field unmasked and set to SCTP. This, I'm assuming, effectively
matches SCTP traffic.
- Build a RAW item for each SCTP src and dst port combination.
- Add QUEUE actions to these patterns  (with different queues for
different src-dst port combinations in the RAW items).

That would be 2^32 flow rules, which I'd guess the hardware wouldn't
accept that many (haven't checked what the limit is yet).
The number of rules could be then reduced by masking some bits in the RAW item.

All of this sounds a bit ridiculous to be honest, but nevertheless, do
you think this is viable? Any similar ideas / improvements? Perhaps,
is there any chance it is possible to perform RSS on flex items?

Sincerely,
Igor.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: net/mlx5 RTE_ETH_RSS_SCTP support
  2024-09-30 23:50   ` Igor Gutorov
@ 2024-10-01 13:58     ` Gregory Etelson
  0 siblings, 0 replies; 4+ messages in thread
From: Gregory Etelson @ 2024-10-01 13:58 UTC (permalink / raw)
  To: Igor Gutorov
  Cc: Bing Zhao, Dariusz Sosnowski, Matan Azrad, Ori Kam, Suanming Mou,
	users, Slava Ovsiienko

[-- Attachment #1: Type: text/plain, Size: 2860 bytes --]

Hello Igor,

I'm checking what solution can fit your requirements.

Regards,
Gregory
________________________________
From: Igor Gutorov <igootorov@gmail.com>
Sent: Tuesday, October 1, 2024 02:50
To: Gregory Etelson <getelson@nvidia.com>
Cc: Bing Zhao <bingz@nvidia.com>; Dariusz Sosnowski <dsosnowski@nvidia.com>; Matan Azrad <matan@nvidia.com>; Ori Kam <orika@nvidia.com>; Suanming Mou <suanmingm@nvidia.com>; users@dpdk.org <users@dpdk.org>; Slava Ovsiienko <viacheslavo@nvidia.com>
Subject: Re: net/mlx5 RTE_ETH_RSS_SCTP support

External email: Use caution opening links or attachments


Hello,

On Sun, Sep 29, 2024 at 12:18 PM Gregory Etelson <getelson@nvidia.com> wrote:
>
> Hello,
>
> > I'm wondering about SCTP RSS support in MLX5 NICs.
> > testpmd does not show ipv4-sctp or ipv6-sctp as supported
>
> MLX5 hardware does not offload SCTP RSS.
>
> Regards,
> Gregory

Thank you for the response!
That is unfortunate.

Do you think it is possible to achieve something similar to RSS
offload using the flow engine?

Let me share a bit more about what I'm trying to do. I have a DPDK
application that I want to add SCTP deduplication to.
One of the challenges is that duplicated packets might have different
IP addresses, but identical SCTP layers, causing these duplicates to
be steered to different Rx queues (and hence different threads) by the
default IP RSS offload.

So, I thought I had few options here:
- disable RSS (not really an option, unfortunately)
- software based (computing RSS hash in software and software steering
the packets, or using global lock-free deduplication tables, or so on)
- hardware based, where RSS would be performed on SCTP ports only,
causing the duplicated packets to be steered to the same Rx queues.
This would allow the usage of per thread deduplication tables and
eliminate some overhead from the software based approach.

Since SCTP RSS offload is not supported, do you think it is possible
to "bypass" this limitation? One idea I had is something along these
lines:
- Build an eth / ipv4  pattern. Where the IP item has the proto_id
field unmasked and set to SCTP. This, I'm assuming, effectively
matches SCTP traffic.
- Build a RAW item for each SCTP src and dst port combination.
- Add QUEUE actions to these patterns  (with different queues for
different src-dst port combinations in the RAW items).

That would be 2^32 flow rules, which I'd guess the hardware wouldn't
accept that many (haven't checked what the limit is yet).
The number of rules could be then reduced by masking some bits in the RAW item.

All of this sounds a bit ridiculous to be honest, but nevertheless, do
you think this is viable? Any similar ideas / improvements? Perhaps,
is there any chance it is possible to perform RSS on flex items?

Sincerely,
Igor.

[-- Attachment #2: Type: text/html, Size: 4865 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-10-01 13:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-08-01 13:01 net/mlx5 RTE_ETH_RSS_SCTP support Igor Gutorov
2024-09-29  9:18 ` Gregory Etelson
2024-09-30 23:50   ` Igor Gutorov
2024-10-01 13:58     ` Gregory Etelson

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