E810/ICE: How to configure RSS to steer GTP-U by inner symmetric 5-tuple?

[MarkLin]

Hi,

I’m trying to steer GTP traffic on an Intel E810 so that:

Goal

• Pin GTP-C (UDP/2123) to q0.

• Spread GTP-U (UDP/2152) to q1..qN by inner 5-tuple, ideally symmetric so UL/DL land on the same queue.

Environment

• NIC: Intel E810-XXV for SFP 159b

• Driver/PMD: net_ice

• Firmware: 4.80 0x8002053c 1.3805.0

• DDP package: ICE COMMS 1.3.55.0

• DPDK: 25.07

What works

• GTP-C pin to q0 works

• GTP-U traffic can do RSS to queues when RSS function is ipv4, just not sure it is based on outer or inner:
  flow create 0 ingress group 1 pattern eth / ipv4 / udp / gtpu / ipv4 src spec 0.0.0.0 src mask 128.0.0.0 / end actions rss queues 1 2 3 4 end / end
  flow create 0 ingress group 1 pattern eth / ipv4 / udp / gtpu / ipv4 src spec 128.0.0.0 src mask 128.0.0.0 / end actions rss queues 1 2 3 4 end / end

Where we’re stuck (switch-engine actions rss)

• packets spread to queues but UL/DL aren’t symmetric (appears L3-only).
• Trying func symmetric_toeplitz:
  ... actions rss func symmetric_toeplitz queues 1 2 3 4 end / end
  fails with Unsupported pattern / Invalid argument.
• Including inner L4 in the pattern still yields L3-only behavior. How can we enable inner L4 as the RSS input set for actions rss on E810’s switch engine?

Questions

1. Does E810 (ICE comms 1.3.55) support inner symmetric 5-tuple hashing for GTP-U via switch-engine actions rss?

2. How can we ensure inner L4 (TCP/UDP) is included in the RSS input set for actions rss? Should we set device-level rss_hf to include TCP/UDP, and how do we select inner vs outer on E810?

3. Is func symmetric_toeplitz (or equivalent symmetric option) supported in this path? If yes, what’s the correct actions rss syntax (types/key/func)?

4. If not supported on the switch engine, what’s the recommended approach to keep UL/DL on the same worker (e.g., device-level knob, TEID/QFI-based steering, or other)?

A minimal working example (testpmd or C) for inner 5-tuple (TCP/UDP) hashing, ideally symmetric, would be very helpful. Thanks!

[Simon-Intel]

Hi MarkLin,

Thank you for reaching out to Intel Support. We acknowledge receipt of your concern and want to assure you that assisting you is our top priority. To effectively troubleshoot the issue you're facing, we require some additional information from your end.

Could you kindly provide the following details?

1. System/Board details
2. Front and back pictures of the network adapter with the product markings clearly visible
3. Was this network card shipped along with the system or purchased separately?

Your prompt response with this information will greatly assist us in diagnosing and resolving the issue as quickly as possible.

We look forward to hearing from you soon.

Best regards,

Simon

Intel Customer Support Technician

[MarkLin]

Hi Simon,

Quick update: our tests run inside a VM with the E810 passed through as a PCIe PF.
• Hypervisor: Proxmox VE 7.4-20, KVM/QEMU (machine type q35)
• The VM also has a virtio NIC for management (not used for DPDK path).

All other details we shared earlier (DDP ice_comms-1.3.55.0, DPDK 25.07, PMD net_ice, FW 4.80 … 1.3805.0, etc.) remain the same.

Could you confirm if GTP-U inner 5-tuple RSS (including symmetric hashing) is supported on E810 in this PF-passthrough VM setup? If PF-side host configuration (FW/DDP load or devlink/ethtool settings) is required, we can coordinate with IT.

Would card photos (front/back with PBA/AA/SN) be helpful, or would host-side details (Proxmox host ice driver/NVM/DDP, devlink outputs) be more useful? Also, would you recommend running on bare metal rather than a PF-passthrough VM for this work?

Thanks,

Mark

[Fikri_Intel]

Hi MarkLin,

Thank you for your response. We truly appreciate your time and effort in working through this case with us. To further assist you, we’ve compiled several public resources and documentation that may provide additional technical details, configuration guidance, and reference materials relevant to your inquiry.

Please see below for the key references:

1- Intel® Ethernet Controller 800 Series Device Personalization (DDP) for Telecommunications Workloads – Technology Guide

https://builders.intel.com/docs/networkbuilders/intel-ethernet-controller-800-series-device-personalization-ddp-for-telecommunications-workloads-technology-guide.pdf

2- Intel® Ethernet Controller E810 DDP for Comms Technology Guide

https://downloadmirror.intel.com/823031/Intel_Ethernet_Controller_E810_DDP_for_Comms_Technology_Guide.pdf

3- DPDK Documentation

https://doc.dpdk.org/guides-25.07/index.html

4- DPDK ICE Advanced RSS Test Plan

https://doc.dpdk.org/dts/test_plans/ice_advanced_rss_test_plan.html

5- Adapter User Guide

https://www.intel.com/content/www/us/en/download/19373/adapter-user-guide-for-intel-ethernet-adapters.html

We recommend reviewing these resources as they cover detailed technical aspects, configuration options, and validation guidelines that may support your testing and deployment activities.

Please don’t hesitate to let us know if you need clarification on any of the documents or require further support.

Regards,

Fikri O.

[MarkLin]

Hi Fikri,

Thanks for the links ! The ICE Advanced RSS Test Plan helped a lot. Using the patterns and examples there, I can get GTP-U UL/DL to land symmetrically on RX queues via RSS.

For reference, one of the rules I’m using is:

flow create 0 ingress group 1 pattern eth / ipv4 / udp / gtpu / ipv4 / tcp / end actions rss func symmetric_toeplitz types ipv4-tcp end key_len 0 queues end / end

What I’m still stuck on is keeping q0 reserved for GTP-C (UDP/2123) only.
With RSS enabled, I still see traffic on q0; I’d like all GTP-U to be steered only to q1..qN.
Is there a supported way on E810 + Comms DDP to exclude q0 from RSS destinations while keeping a separate switch rule (GTP-C→q0) active? A minimal testpmd recipe would be perfect if you have one.

If excluding q0 isn’t supported, we can proceed and handle q0 in software side. I just want to confirm whether there’s a proper configuration I’m missing.

Best,
Mark

[Simon-Intel]

Hi MarkLin,

Thank you for your response.

To support you more effectively, could you kindly share front and back pictures of the network adapter with the product markings clearly visible?

Your prompt response will help us assist you better.

Regards,

Simon

Intel Customer Support Technician

[MarkLin]

Hi Simon,

Thanks for your support!

• Board: Asus B660M-C
• And this network card was purchased separately.
• Pictures of the network adapter:

Best,

Mark

[Sachinks]

Hello MarkLin,

Good day!

Thank you for the details and the images. We are checking this further with our Internal team and we will get back to you with an update at the earliest.

Regards,

Sachin KS

Intel Customer Support Technician

[Sachinks]

Hello MarkLin,

We are checking this further with our* Internal team. Apologies for the typo.

Regards,

Sachin KS

Intel Customer Support Technician

[Sachinks]

Hello MarkLin,

Greetings!

We are sorry for the delay. We understand that this is taking a while however we are still working on this with our internal team and we will get back to you with an update at the earliest. Thank you for your cooperation.

Regards,

Sachin KS

Intel Customer Support Technician

[Sachinks]

Hello MarkLin,

Greetings!

We have checked this with our team and may I ask you to confirm if you have tried mentioning the queue numbers from 1 to 4 in below testpmd command to steer GTP-U to q1-n.

flow create 0 ingress group 1 pattern eth / ipv4 / udp / gtpu / ipv4 / tcp / end actions rss func symmetric_toeplitz types ipv4-tcp end key_len 0 queues end / end

For example, instead of above command, kindly try :

flow create 0 ingress group 1 pattern eth / ipv4 / udp / gtpu / ipv4 / tcp / end actions rss func symmetric_toeplitz types ipv4-tcp end key_len 0 queues 1 2 3 4 end / end

Kindly confirm the above and let us know.

Thank you for using Intel products and services.

Best Regards,

Sachin KS

Intel Customer Support Technician

[MarkLin]

Hi Sachin,

 Yes, I tried mentioning queue index before and failed in flow creation.

 Here is the result of command you provide:

testpmd> flow create 0 ingress group 1 pattern eth / ipv4 / udp / gtpu / ipv4 / tcp / end actions rss func symmetric_toeplitz types ipv4-tcp end key_len 0 queues 1 2 3 4 end / end
ICE_DRIVER: ice_flow_create(): Failed to create flow
port_flow_complain(): Caught PMD error type 13 (specific pattern item): cause: 0x7ffe8d2b3608, Unsupported pattern: Invalid argument

Best,

Mark

[Sachinks]

Hello MarkLin,

Thank you for your reply!

Thank you for providing us the update. We will check this further with our team and get back to you at the earliest.

Regards,

Sachin KS

Intel Customer Support Technician

[Sreelakshmi1]

Hi MarkLin,

Greetings!

We would like to inform you that we are currently coordinating with the Engineering team to investigate this further and will provide an update shortly. 

Thank you for your patience.

Best Regards,

Sreelakshmi

Intel Customer Support Technician

[Azhari_Intel]

Hello MarkLin,

Good day to you!

Please accept our apologies for the delay.

Proceeding further, may I kindly request for you to attempt below command, more or less similar.

port config 0 rss reta (0,1) (1,2) (2,3) (3,1) (4,2) (5,3) (6,1) (7,2) (8,3) (9,1) (10,2) (11,3) (12,1) (13,2) (14,3) (15,1)

Do let us know if this helps the 'flow create' commands that you had created.

Best Regards,

Azhari_Intel

[Azhari_Intel]

Hi MarkLin,

Good day to you.

Just wanted to follow up with you, kindly let us know if you have any further concerns.

Looking forward to your response.

Regards,

Azhari_Intel

[Azhari_Intel]

Hi MarkLin,

Greetings!

As it has been a while since we last heard from you, I wanted to follow up with you on this.

Please let us know if you have the opportunity to attempt the command provided earlier.

If you require further time or have an ETA on when the provided suggestion may be perform from your side, kindly let us know.

For now, we shall continue to monitor the thread for two (2) days before this thread being unmonitored.

Best Regards,

Azhari_Intel

[MarkLin]

Hi Azhari_Intel,

Sorry for late reply!
I'll try to have test with command you provide in the coming days.

Thanks!

Mark

[IntelSupport]

Hi Mark Lin,

Greetings for the day!

Noted, we will wait for your response.

Regards

Jerome

Intel Customer Support Technician

[MarkLin]

Hi !

I'd like to check with you again that what I need to test is, if rss reta setup on those queues helps to resolve error while doing
flow create 0 ingress group 1 pattern eth / ipv4 / udp / gtpu / ipv4 / tcp / end actions rss func symmetric_toeplitz types ipv4-tcp end key_len 0 queues 1 2 3 4 end / end
command. Am I correct ?

I just setup rss reta:

testpmd> show port 0 rss reta 512 (0xffffffffffffffff,0xffffffffffffffff,0xffffffffffffffff,0x0,0x0,0xffffffffffffffff,0xffffffffffffffff,0xffffffffffffffff)

RSS RETA configuration: hash index=0, queue=1
RSS RETA configuration: hash index=1, queue=2
RSS RETA configuration: hash index=2, queue=3
RSS RETA configuration: hash index=3, queue=1
RSS RETA configuration: hash index=4, queue=2
RSS RETA configuration: hash index=5, queue=3
RSS RETA configuration: hash index=6, queue=1
RSS RETA configuration: hash index=7, queue=2
RSS RETA configuration: hash index=8, queue=3
RSS RETA configuration: hash index=9, queue=1
RSS RETA configuration: hash index=10, queue=2
RSS RETA configuration: hash index=11, queue=3
RSS RETA configuration: hash index=12, queue=1
RSS RETA configuration: hash index=13, queue=2
RSS RETA configuration: hash index=14, queue=3
RSS RETA configuration: hash index=15, queue=1
RSS RETA configuration: hash index=16, queue=2
RSS RETA configuration: hash index=17, queue=3
RSS RETA configuration: hash index=18, queue=1
RSS RETA configuration: hash index=19, queue=2
RSS RETA configuration: hash index=20, queue=3
RSS RETA configuration: hash index=21, queue=1
RSS RETA configuration: hash index=22, queue=2
RSS RETA configuration: hash index=23, queue=3
RSS RETA configuration: hash index=24, queue=1
RSS RETA configuration: hash index=25, queue=2
RSS RETA configuration: hash index=26, queue=3
RSS RETA configuration: hash index=27, queue=1
RSS RETA configuration: hash index=28, queue=2
RSS RETA configuration: hash index=29, queue=3
...
RSS RETA configuration: hash index=508, queue=2
RSS RETA configuration: hash index=509, queue=3
RSS RETA configuration: hash index=510, queue=1
RSS RETA configuration: hash index=511, queue=2

And then try to create flow:
testpmd> flow create 0 ingress group 1 pattern eth / ipv4 / udp / gtpu / ipv4 / tcp / end actions rss func symmetric_toeplitz types ipv4-tcp end key_len 0 queues 1 2 3 end / end
ICE_DRIVER: ice_flow_create(): Failed to create flow
port_flow_complain(): Caught PMD error type 13 (specific pattern item): cause: 0x7ffd912665e8, Unsupported pattern: Invalid argument

Failed again but now cause: 0x7ffd912665e8  is different ?

[Sazirah]

Hi MarkLin,

Greetings.

Regarding this issue, we would like to check if you get a chance to go through the relevant DPDK documentation page in regards to the test plan. You may refer to link provided below for your reference:

DPDK link: 

1) https://doc.dpdk.org/dts/test_plans/ice_advanced_rss_gtpu_test_plan.html 

2) https://doc.dpdk.org/guides/nics/ice.html

Regards,

Sazzy_Intel

Intel Customer Support Technician