From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AF700A0032; Wed, 14 Sep 2022 11:57:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 573064021D; Wed, 14 Sep 2022 11:57:32 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 16B1440156 for ; Wed, 14 Sep 2022 11:57:31 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B9CB45C0061; Wed, 14 Sep 2022 05:57:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 14 Sep 2022 05:57:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1663149450; x= 1663235850; bh=FojyZR7GgvKt74LmOBmKGAkuXHAKpepBgZZ/9abuajs=; b=I rR7hRa0wTmf3o0D/lWPvQBH6jUYYSp5ulXdvlNRmTA8x10MUSvRVpmhwxoAfoPII CmyGyy/NvbQOWQ43kBFtrPKEansv6LvifuWmzkAI3t0YP+4SnFnjAnw6PrT99vP5 VM32OiDLQI22OrJlnOMg0Z06dkE5px8751tjFGkmEAp5GXXYle+/p34DZDJOFufJ klgJk1FCeeLZe9rOfYqQGYD04uk0bnKSQ7cPba3pZUyAzGLwCVDKrDivPxaC5Nn7 o8Cprv4IsvNrTuKadMIp6Qn7jEmmeU3/yCtDzphNrMrG0PNZsUfLVPylBzhQ5TZL +i5/p9rd6ywsuVTcWn04w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1663149450; x= 1663235850; bh=FojyZR7GgvKt74LmOBmKGAkuXHAKpepBgZZ/9abuajs=; b=a uGLa/36IQbfwHdkHZ3xzJ2WnwzXBjZvOK4VGLa+gAYBh5qWrTBOQ3cxVQYplWSBn T7SU1iQZCXNbVal+K1VE99XkdOIg4I/+xXV24vZcFgvVxHcpyORem916SXohAT1m cGFK4eiVUXlRExUXTafTMYO6tC3N/evB0HHcKOK554Kp8hlJJ1HZ5H2EfcQggrmC 1j4pfUaoBb7m+o/2BPnqE7cvrAMtUm4UyVZ3BmHYPrtvNFhfv11H1u72taWSPza6 UJl13eEhR7IHT0ds/WhBCe/DrXEYejnbhFZVj59Q9hc7ffH2DMo1FeAChPQDVleF pyaw46dR4dmwoqfm/5qgA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeduiedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 14 Sep 2022 05:57:29 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko , Ori Kam , Michael Savisko Cc: "dev@dpdk.org" , Ferruh Yigit , Slava Ovsiienko Subject: Re: [RFC] ethdev: add send to kernel action Date: Wed, 14 Sep 2022 11:57:28 +0200 Message-ID: <1759351.3VsfAaAtOV@thomas> In-Reply-To: References: <20220811113544.1718643-1-michaelsav@nvidia.com> <64fd910d-f63e-0f5b-ce66-89132671ddbd@oktetlabs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 13/09/2022 14:09, Michael Savisko: > From: Andrew Rybchenko > > On 9/12/22 16:39, Michael Savisko wrote: > > > From: Thomas Monjalon > > >> 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 > > >>> > > >>> 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.