On 9/12/22 16:39, Michael Savisko wrote:
-----Original Message-----
From: Thomas Monjalon <tho...@monjalon.net>
Sent: Monday, 12 September 2022 16:33
To: Michael Savisko <michael...@nvidia.com>; Ori Kam <or...@nvidia.com>
Cc: andrew.rybche...@oktetlabs.ru; dev@dpdk.org; Ferruh Yigit
<ferruh.yi...@xilinx.com>; Slava Ovsiienko <viachesl...@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 <michael...@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?
