From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1E7A8A057D; Wed, 18 Mar 2020 16:07:19 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0ABBE292D; Wed, 18 Mar 2020 16:07:18 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id EF277FEB for ; Wed, 18 Mar 2020 16:07:15 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7D4895C028D; Wed, 18 Mar 2020 11:07:13 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 18 Mar 2020 11:07:13 -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=mesmtp; bh=2x97eOziyCQJaEJBdIgKFHsJpG5uy02UhpMEagoZqXc=; b=SQxMXlorX0xc ibFyQcgIF3oa+NXS9zo4xwlKTeQqKLY/KxnMVNsu1gdc4lY8Se2hgFoHXARUG7bN BwwPrrJx4inb6P4PmVHNweqj7UAZOqDJVEkiisRHMzjy5pUtYi9kawcUtrC/+0sd PX0A10DT67PNYBmm1OC9A0c1py9WmRs= 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=fm2; bh=2x97eOziyCQJaEJBdIgKFHsJpG5uy02UhpMEagoZq Xc=; b=bZJFvkHPFmlYIBj/pRtZCqYCcV3HxwSff0FuUldaMVx3OU7EHItgEjvYs xGFJEGtauBlVtsbLKMadF+UNta6dl1RS2aLy6LkYTlltPwSJywerq+w3Iy0rpe1V EMY9OmiezkyJgADtL8O0e0Dh9tjwPhvB6hYCAUzNPyOlFAT9yEu1E/g2Yu1Vfpt8 4i4gMv9a3QtgHDyqtfKHQGkpMb92IJeAB/VZftdFOy8IYJi1rnJLSXV3M1FHfgVV zuZxKVqs+6xBM4aqHb1JMlNsHXsjRmRY8Eh2kh1dXcuzBYxXCY8MOKccVko8FKUP Gt/vuAdEkCO+3fsmMccH74723GlOQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3BEAA3280059; Wed, 18 Mar 2020 11:07:11 -0400 (EDT) From: Thomas Monjalon To: Rahul Lakkireddy Cc: kaara.satwik@chelsio.com, dev@dpdk.org, nirranjan@chelsio.com, ferruh.yigit@intel.com, orika@mellanox.com Date: Wed, 18 Mar 2020 16:07:07 +0100 Message-ID: <1898757.kUgFBCI4xA@xps> In-Reply-To: <20200318130614.GA24949@chelsio.com> References: <18214127.sIn9rWBj0N@xps> <20200318130614.GA24949@chelsio.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 0/9] net/cxgbe: updates for rte_flow support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" 18/03/2020 14:06, Rahul Lakkireddy: > Hi Thomas, > > On Wednesday, March 03/18/20, 2020 at 13:09:47 +0100, Thomas Monjalon wrote: > > 11/03/2020 10:05, Rahul Lakkireddy: > > > From: Karra Satwik > > > > > > This series of patches contain rte_flow support for matching > > > Q-in-Q VLAN, IP TOS, PF, and VF fields. Also, adds Destination > > > MAC rewrite and Source MAC rewrite actions. > > > > > > Apart from the 4-tuple (IP src/dst addresses and TCP/UDP src/dst > > > port addresses), there are only 40-bits available to match other > > > fields in packet headers. Currently, the combination of packet > > > header fields to match are configured via filterMode for LETCAM > > > filters and filterMask for HASH filters in firmware config files > > > (t5/t6-config.txt). Adapter needs to be reflashed with new firmware > > > config file everytime the combinations need to be changed. To avoid > > > this, a new firmware API is available to dynamically change the > > > combination before completing full adapter initialization. So, 2 > > > new devargs filtermode and filtermask are added to dynamically > > > select the combinations during runtime. > > > > Please, could you explain why you are using devargs for flow matching, > > instead of using the common and generic rte_flow API? > > The devargs are being used to configure the TCAM in hardware on > what header fields need to be matched in packets by the TCAM. The > actual filter rules are still being inserted using rte_flow API. > > Apart from the 4-tuple (src/dst IP, src/dst port addresses), there > are only 40-bits available for each filter rule to match other > header fields. Hardware supports matching ethertype (16-bit), > DST MAC (9-bit MPS index), Inner VLAN (16-bit), Outer VLAN (16-bit), > IP Protocol (8-bit), IP TOS (8-bit), Ingress Physical Port (3-bit), > and PFVF (17-bit) for now. It's not possible to write a filter rule > which wants to match all the above fields, which is far beyond 40-bits > available. So, the devargs are being used to control which of the > above fields that user wants to configure the TCAM to match. Note > that once the TCAM is configured, "all" the rules in the TCAM can > only match the selected fields in the combination. They can't match > any other header fields. In case a rule is not possible, are you rejecting it at the validation stage? > For example, let's say user wants to match ethertype (16-bit), > DST MAC (9-bit MPS index), and IP protocol (8-bit) in all filter > rules. Then, they would configure the TCAM with the {ethertype, > DST MAC, and IP protocol} combination. All rules that the user > wants to insert into TCAM can only have the above header fields, > alongside the default 4-tuple (src/dst IP, src/dst port addresses). > > There are 2 regions in hardware. One for matching wild-card filter > rules and the other for matching exact-match rules. The "filtermode" > devarg controls the 40-bit combination for wild-card filter rules and > the "filtermask" devarg controls the combination for exact-match rules. I see an issue with this approach. I will explain below. An application is written to use some flow rules. The application requirements are expressed by the app developper through the API (rte_flow). In your case, the user must be aware of what the application expects and fill the right devargs, according to what the dev wrote. Why bothering the user with this constraint? I understand the hardware must be prepared in advance. I think this configuration must be done through API. One workaround is to manage this HW limitation in a PMD-specific API. A good solution would be to express this requirement with rte_flow. One idea: can we use rte_flow_validate() to fill the requirements? The PMD requirements are empty at the beginning and they are filled with the first calls to rte_flow_validate(). Maybe we also need to express the capabilities/limitations. Example: is there a maximum number of rules? maximum number of protocols to match? maximum number of bits to match? I suppose it is not easy to implement. Comments?