On 9/12/22 16:39, Michael Savisko wrote:
-----Original Message-----
From: Thomas Monjalon <[email protected]>
Sent: Monday, 12 September 2022 16:33
To: Michael Savisko <[email protected]>; Ori Kam <[email protected]>
Cc: [email protected]; [email protected]; Ferruh Yigit
<[email protected]>; Slava Ovsiienko <[email protected]>
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 <[email protected]>
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?
