13/09/2022 14:09, Michael Savisko: > From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> > > On 9/12/22 16:39, Michael Savisko wrote: > > > From: Thomas Monjalon <tho...@monjalon.net> > > >> 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. > > 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.
Should we add this note in the doxygen comment? This is the wording in the v2 sent today: + /* + * Send packets to the kernel, without going to userspace at all. + * The packets will be received by the kernel driver sharing + * the same device as the DPDK port. + * + * No associated configuration structure. + */ + RTE_FLOW_ACTION_TYPE_SEND_TO_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 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.
