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 7A2F5A0547; Wed, 29 Sep 2021 20:52:50 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 05E18410EA; Wed, 29 Sep 2021 20:52:50 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 8D7EB410E5 for ; Wed, 29 Sep 2021 20:52:48 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3BB6B5C009D; Wed, 29 Sep 2021 14:52:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 29 Sep 2021 14:52:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= BNFI6Lg2g8PR9gkFAWuSGMVnZIo+CFwAKYluSu269II=; b=EH0w0GSrQys0Trls tERx1os5NhqDsaXz3qH7RL2AC6lQWNbqUl4FgDEaF1cUIjUszp33nGcdKLHFmWzz msGF8LM8ZxQNrvCiz9U3MPGEWm7WIyOB3cJdktsIPENL53JBphOHZ0/FP7nvZsF6 GYw/qS0KnfSyI5MNlUUflPxXjijCxt5CANgdkFDIZabFjgRp2HVdpzCSu0/etb0x 3Tq2Vm9LSi1RcXNYppcWUZdwOP4yot2RpV+Tggzp5jNUlOrbhIKdb+56sU0Ftm+N 3qMEWji7lo1oeDsG2+MCSlFQipWp+SuEl/vQoHvHdjwECN71YLohVV9pJ6+CbMid jdKU+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=BNFI6Lg2g8PR9gkFAWuSGMVnZIo+CFwAKYluSu269 II=; b=auRyOxerFvYgL9s8NLy7RYrxg29ZdsRwXPXMizfhSirBnBu2j/KTmQZPw Jnnow3S/ty+B7hRFbswd6NAyRyQHiI8cOqcOX4H+QMW02LhX1xUDPEQhA2jupRnH 0CtiHNZp3WmfZUpgTEL2MFeHoKev5vnSr4kkC5V1ItK40XXXTJW2KZ4RDIZiKHnK AWatQ9sMB/RFSs26Ei5o1SyDyKyqP23WWyr4nRwgPNPy0otGtGWbZ6ly8UIhUZrh K099/zR/29+fg6gddT93RrHqYKhGFiFnqk9pGxCvvymyBucPoojAjBzm1GIEmiHu nRcZxjOK4JGkYkmXexpEhssSQHj5w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudekvddguddvkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 29 Sep 2021 14:52:44 -0400 (EDT) From: Thomas Monjalon To: Ori Kam , Stephen Hemminger Cc: dev@dpdk.org, andrew.rybchenko@oktetlabs.ru, ferruh.yigit@intel.com Date: Wed, 29 Sep 2021 20:52:43 +0200 Message-ID: <2188270.3AJhsh48eD@thomas> In-Reply-To: <20210929104436.6fd88409@hermes.local> References: <20210929104436.6fd88409@hermes.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] Querying for rte_flow support? 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 Sender: "dev" 29/09/2021 19:44, Stephen Hemminger: > Have a problem with auto-detecting whether device driver supports rte_flow. > > Ideally in application would like to be able adapt to handle devices that > do rte_flow and those that do not. If device does not support rte_flow, > then configure with RSS across multiple cores; if device does support rte_flow > then assign traffic to queue based on match (on MAC). > > The problem is that there really is not a good API in DPDK for checking. > Most device drivers will not give the correct return to rte_flow_validate > unless the device is configured already, and some require device to be started. > In order to configure, the application has to choose how many queues to use > and that is the reason it wants to know if rte_flow will work! > > The other alternative is looking at DPDK internal data structs to see > if device supports flow operations. That is not good, and causes more > issues in later releases. > > Looks like rte_flow has a "chicken/egg problem" here. I think we just need to fix drivers implementation of rte_flow_validate(). We must be able to validate a flow before starting the device. Which drivers are refusing such check? That's something we can check with some unit tests.