Technically feasible? | rx packet distribution -> duplications | E810/E823

Technically feasible? | rx packet distribution -> duplications | E810/E823

[Dominik]

Hello everybody

I am currently working on a project to implement the following use
cases with high performance.
The main workload should be offloaded to the hardware to achieve
optimal performance.

## Environment

Kernel: 6.8.12
DPDK: 24.11.1
NIC: Intel 810 / Intel E823

## Use Case / Requirements

- Ingress packet distribution to different software endpoints (queues)
- Utilization of hardware timestamp offloading
- A single packet in multiple queues
- Implementation of filters in hardware


### Examples:

1)
    RX  ->  Queue-01  [TCP only]
        ->  Queue-02  [UDP only]

2)
    RX  ->  Queue-01  [all packets]
        ->  Queue-02  [TCP only]
        ->  Queue-03  [src.mac == xx.xx…]
2)
    RX  ->  Queue-01  [all packets]
        ->  Queue-02  [TCP only]
        ->  Queue-03  [src.mac == xx.xx…]
        ->  Queue-04  [vlanid == ##]

3)
    RX  ->  Queue-01  [all packets]
        ->  Queue-02  [TCP && vlanid == ##]

## Ideas / Notes/ Issues

- Filtering by desired parameters with rte-flow tested
- Using the desired queue is also functional
- Many combinations have been tested successfully
- A packet in multiple queues
 - Issue:
  - DPDK does not allow multiple destinations in rte-flow
  - Thus, no throughput, packet duplication
 - Idea:
  - HW port mirroring to a virtual port and using this port for
further operations
  - Code in the ice driver partially prepared ?!


## Questions

1) Is this approach feasible with E810/E823 hardware (regardless of
current software implementations)?

2) If yes, would port mirroring be a suitable method, or is there a
better approach for this use case?
2a) With the current implementation
2b) With potential adjustments/extensions

3) In the case of port mirroring:
3a) Is the hardware timestamp preserved?
3b) Can additional filters be applied on the VF?


Best regards,
Dominik

Re: Technically feasible? | rx packet distribution -> duplications | E810/E823

[Dominik Kies]

Hello again,

in addition, I have seen that Mellanox has the Action Type Sample.
This should be exactly what I am looking for, or am I misinterpreting
this? Is this not supported by the hardware or is there just a lack of
implementation in the driver?

best regards
Dominik Kies


On Thu, Feb 6, 2025 at 4:11 PM Dominik <dokibyte@gmail.com> wrote:
>
> Hello everybody
>
> I am currently working on a project to implement the following use
> cases with high performance.
> The main workload should be offloaded to the hardware to achieve
> optimal performance.
>
> ## Environment
>
> Kernel: 6.8.12
> DPDK: 24.11.1
> NIC: Intel 810 / Intel E823
>
> ## Use Case / Requirements
>
> - Ingress packet distribution to different software endpoints (queues)
> - Utilization of hardware timestamp offloading
> - A single packet in multiple queues
> - Implementation of filters in hardware
>
>
> ### Examples:
>
> 1)
>     RX  ->  Queue-01  [TCP only]
>         ->  Queue-02  [UDP only]
>
> 2)
>     RX  ->  Queue-01  [all packets]
>         ->  Queue-02  [TCP only]
>         ->  Queue-03  [src.mac == xx.xx…]
> 2)
>     RX  ->  Queue-01  [all packets]
>         ->  Queue-02  [TCP only]
>         ->  Queue-03  [src.mac == xx.xx…]
>         ->  Queue-04  [vlanid == ##]
>
> 3)
>     RX  ->  Queue-01  [all packets]
>         ->  Queue-02  [TCP && vlanid == ##]
>
> ## Ideas / Notes/ Issues
>
> - Filtering by desired parameters with rte-flow tested
> - Using the desired queue is also functional
> - Many combinations have been tested successfully
> - A packet in multiple queues
>  - Issue:
>   - DPDK does not allow multiple destinations in rte-flow
>   - Thus, no throughput, packet duplication
>  - Idea:
>   - HW port mirroring to a virtual port and using this port for
> further operations
>   - Code in the ice driver partially prepared ?!
>
>
> ## Questions
>
> 1) Is this approach feasible with E810/E823 hardware (regardless of
> current software implementations)?
>
> 2) If yes, would port mirroring be a suitable method, or is there a
> better approach for this use case?
> 2a) With the current implementation
> 2b) With potential adjustments/extensions
>
> 3) In the case of port mirroring:
> 3a) Is the hardware timestamp preserved?
> 3b) Can additional filters be applied on the VF?
>
>
> Best regards,
> Dominik