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 32BDFA057B; Wed, 18 Mar 2020 14:16:59 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5B53EFEB; Wed, 18 Mar 2020 14:16:58 +0100 (CET) Received: from stargate.chelsio.com (stargate.chelsio.com [12.32.117.8]) by dpdk.org (Postfix) with ESMTP id EB00CE07 for ; Wed, 18 Mar 2020 14:16:56 +0100 (CET) Received: from localhost (scalar.blr.asicdesigners.com [10.193.185.94]) by stargate.chelsio.com (8.13.8/8.13.8) with ESMTP id 02IDGsrt011164; Wed, 18 Mar 2020 06:16:55 -0700 Date: Wed, 18 Mar 2020 18:36:15 +0530 From: Rahul Lakkireddy To: Thomas Monjalon Cc: kaara.satwik@chelsio.com, dev@dpdk.org, nirranjan@chelsio.com, ferruh.yigit@intel.com, orika@mellanox.com Message-ID: <20200318130614.GA24949@chelsio.com> References: <18214127.sIn9rWBj0N@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18214127.sIn9rWBj0N@xps> User-Agent: Mutt/1.5.24 (2015-08-30) 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" 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. 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. Thanks, Rahul