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 99A0DA0032; Mon, 12 Sep 2022 15:14:50 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 76217400D4; Mon, 12 Sep 2022 15:14:50 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 2B3744003C for ; Mon, 12 Sep 2022 15:14:49 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B2ED75C00DE; Mon, 12 Sep 2022 09:14:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 12 Sep 2022 09:14:48 -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=1662988488; x= 1663074888; bh=bZReKujAuBC0qh+PquowVixVNfyEMHn62n+7zXYPv58=; b=1 IKV0xUBqK5zso7UR3Flo9VsWIuYes1TUwsv/DzW+iOVWNst0NQM68ah+386yZ5HU W44MfdZEnjVKfjmDuTL8iVAvoWv8NVI+4H6m8SfXo7+6b7YsDo1H4/k4rZZ3n0HC oYAHZev5KIpLP3WAmeCuL1Y9TcGkvPAHhNPtAV3H5TfdfE7SRAU9PWNJe5SPwBNf bnwKGCUxNkJ60lO14eKAZp9ksCzT3uglqti3r+1OloSE1IpC0EX9VMjyg+tspttK cXyHOxnM5J1bp90Q94QmkU/mRmQAK7FVq4ZpJ2EjYhrix8/gN8BRg7kzNteydOBl 0vORBhA6SyfwRzAFE81Dg== 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=1662988488; x= 1663074888; bh=bZReKujAuBC0qh+PquowVixVNfyEMHn62n+7zXYPv58=; b=g PZ9gvshY7s+jGOoqdIoLycpTO8vZK12XGa8gGkQABk0mtaYTxflvUSXOIYwD3PNG Tp8djTNVjQ2cUKzxiAHlE9pDUNr3V6jZ1m5XqLY3h+QJ/o+Am+ibhdW71Zv6moCD t9GJZg9Cj9YsOuzY7JiGjyl+hrWRNXlFEv6nJwj1rNW8LQ23A9kNCFQ0OIqVcImr OozkLAvslWIAssWaoSuzEfKa8VGOed0LLdCsmAijtwuBNfiWkvKGlVTmZwxi9VJj vjz+1EumAdFChnATVO8rOsZ5pYK6i+HVxQyi0tO/Xop/xX8nvcsg26GXOZMdcQLT KaueQHl85RMHcj0tguguA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeduvddgieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 12 Sep 2022 09:14:47 -0400 (EDT) From: Thomas Monjalon To: Michael Savisko Cc: dev@dpdk.org, asafp@nvidia.com, orika@nvidia.com, Ferruh Yigit , Andrew Rybchenko Subject: Re: [PATCH 1/3] ethdev: add send to kernel action Date: Mon, 12 Sep 2022 15:14:45 +0200 Message-ID: <2195181.iZASKD2KPV@thomas> In-Reply-To: <20220912125908.922188-1-michaelsav@nvidia.com> References: <20220912125908.922188-1-michaelsav@nvidia.com> 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 Hi, Please don't split ethdev, testpmd and doc in different patches. They are all very related and may come together in a single patch. 12/09/2022 14:59, Michael Savisko: > 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. You should mention bifurcated driver capability: in isolated mode, with mlx5, we can receive directly in the kernel. Are we able to do the same with Linux TC rules? > This commit introduces rte flow action that the application may use > to route the packet to the kernel while still in the HW. Should we understand it is the opposite of isolated mode? [...] > + /* > + * Send traffic to kernel. > + */ You should make explicit that the traffic is directed to the kernel, without going to userspace at all. A reference to the isolated mode would be worthwhile as well. > + RTE_FLOW_ACTION_TYPE_SEND_TO_KERNEL,