[RFC] ethdev: add send to kernel action

[Andrew Rybchenko]

On 9/12/22 16:39, Michael Savisko wrote:
>> -----Original Message-----
>> From: Thomas Monjalon <thomas at monjalon.net>
>> Sent: Monday, 12 September 2022 16:33
>> To: Michael Savisko <michaelsav at nvidia.com>; Ori Kam <orika at nvidia.com>
>> Cc: andrew.rybchenko at oktetlabs.ru; dev at dpdk.org; Ferruh Yigit <ferruh.yigit at xilinx.com>; Slava Ovsiienko <viacheslavo at nvidia.com>
>> Subject: Re: [RFC] ethdev: add send to kernel action
>> 
>> 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 at 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.

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

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 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?