RE: [RFC] ethdev: add send to kernel action

[Michael Savisko <michaelsav@nvidia.com>]

> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Monday, 12 September 2022 17:41
> 
> On 9/12/22 16:39, Michael Savisko wrote:
> >> -----Original Message-----
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >> Sent: Monday, 12 September 2022 16:33
> >>
> >> 16/08/2022 11:50, Ferruh Yigit:
> >>> On 8/11/2022 12:35 PM, Michael Savisko wrote:
> >>>>
> >>>> In some cases application may receive a packet that should have
> >>>> been received by the kernel. In this case application uses KNI or
> >>>> other means to transfer the packet to the kernel.
> >>>> This commit introduces rte flow action that the application may use
> >>>> to route the packet to the kernel while still in the HW.
> >>>>
> >>>> Signed-off-by: Michael Savisko <michaelsav@nvidia.com>
> >>>
> >>> I assume this only works for bifurcated drivers, right?
> >>
> >> This question has not been replied after a month.
> >> Please let's be more reactive.
>  >
>  > Depends on HW. If it can forward packets to different places then it can also
> be supported. But in most cases yes - for bifurcated drivers.
> 
> The action sounds like "do some magic". As far as I know we have no concept of
> kernel and cooperation with the kernel in DPDK yet.

There's nothing "magical". Kernel is not a part of DPDK, but DPDK can use KNI to transfer messages between application and kernel.
With bifurcated driver we can have a rule to route the packet matching a pattern (example: IPv4 packets) to the DPDK application and the rest of the traffic will be received by the kernel. 
But if we want to receive most of the traffic in DPDK except specific pattern (example: ICMP packets) that should be processed by the kernel, then it's easier to re-route these packets with a single rule.
The new action I'm suggesting allows application to route packets directly to the kernel without software involvement, it is a HW offload.
We see it used when working with bifurcated driver, because the kernel driver and the DPDK driver are sharing the same HW.

> Is it a transfer or non-transfer action?
> I guess non-transfer, since otherwise the next question is which kernel...

This is an ingress action only.

> In the case of non-transfer DPDK has a concept of Rx queues which are used to
> deliver traffic to and we have QUEUE and RSS flow actions to do it.

The idea of this offload action is to route traffic away from the DPDK application.

> The patch adds some magic direction "kernel". Don't we want to control
> destination queue? RSS?
> May be we need dedicated control steps to setup kernel Rx queues and than use
> QUEUE/RSS to direct traffic there?

We have no control of how the kernel is configured.

I will provide a new version of the patch with better documentation. Please feel free to suggest any wording.

Thank you,
Michael