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 20757A0032; Wed, 14 Sep 2022 07:16:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 135F44021D; Wed, 14 Sep 2022 07:16:58 +0200 (CEST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2050.outbound.protection.outlook.com [40.107.93.50]) by mails.dpdk.org (Postfix) with ESMTP id 83A6840141 for ; Wed, 14 Sep 2022 07:16:56 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=emdW4j/9E24fKePbqBqWRpSaNxk29T97hKO4w3cQHPkSGOoKniY669Db+sFE9KbmAHD5maMV80ODUEK5m7UjJoWCWuAeiYGQiM8cQaNKZudHWM3Q1qkWlgsd8jjOgJAjtosIzJ2XmqMoVfvBqIxlZzMBWviMuZl8H4Gaw9kTWZfq90H6Uwc2mXftfpEDrRGAqzHhg+4GmhtQQqtL+aRr6y+k/HpERGYw2pQtoE5peJI4j7R0enfSx0QkA/1mky4ma9dMrymX8w/TRKrnLqrsXgcj6IEgbubJwBBaonRMvd0osBA2UiuGF/hYiBTjMKE5KV6pj9rOzoiuVAafLfWxKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=l/RrJNJozcokO0O+Ps4ks3N7oAA+E++bdNz5/F3Zxkw=; b=IoCK0PFSmPrj8puitmfO8vZVOGMeZsHvUPhdcl73okBbeDX8POctVurH0STSI+F2inkgeFdC6S0qZhBeYYMiz/ehHoAY+CdhxypKTMkA7jypnB+P/CN9cJP4jHoPutN1xF1PDKCy1EovoVGz+Mj0dGIbvQKMbENwQfbo9pOBxqk0oEGrapAqrn94bXYhUgXaTZX7JU1cM2CljIRvTowOaMarIMHFjm4h3SimkVRXOSAVTKEnsK+vgiaiuw1+dXtg4u3rSMLyAZcw06nhSV2PiZ/tnKkFEbXlIcfK9dZIFdZiEg7fVARucz4Rsij7KMZYs3Y7zYTCCkj5WR1We+uJUA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l/RrJNJozcokO0O+Ps4ks3N7oAA+E++bdNz5/F3Zxkw=; b=oavZipSySdZAlYENZqTAt+2iSr8efNSCPrUcD0k7tyV6gXsSbveobWoI5iPmAOzLXDj5QZ/1XtCtek/d32PbuKF8PH7cUrefKjeH7Fs2HU25ChCphMX7JeftjU2COdsJ3aYiFHfttKpOLsgokIXUGQjQWVeIYonicVo63zs4opXgUusA987rYHgUJG+Cq3a8VeSs0/Yh8KtezzAMK8nOuJgXCQ2uZE75mh78rJ6ttu8HcxGbhmkTY/dHZn9185XNn6lVZMwwR0QT1+zzTBGNfAoiQXOIq/jIiBGE2TxH23aISuOC8k301UEkkJ8EpUKJpHh78N2hu7KmlCahFqu6Jw== Received: from BN9PR12MB5273.namprd12.prod.outlook.com (2603:10b6:408:11e::22) by BN9PR12MB5365.namprd12.prod.outlook.com (2603:10b6:408:102::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.19; Wed, 14 Sep 2022 05:16:52 +0000 Received: from BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::a426:af46:a459:d88b]) by BN9PR12MB5273.namprd12.prod.outlook.com ([fe80::a426:af46:a459:d88b%5]) with mapi id 15.20.5612.022; Wed, 14 Sep 2022 05:16:52 +0000 From: Rongwei Liu To: Ivan Malov CC: Matan Azrad , Slava Ovsiienko , Ori Kam , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Aman Singh , Yuying Zhang , Andrew Rybchenko , "dev@dpdk.org" , Raslan Darawsheh Subject: RE: [PATCH v1] ethdev: add direction info when creating the transfer table Thread-Topic: [PATCH v1] ethdev: add direction info when creating the transfer table Thread-Index: AQHYwmNUlJ87k3rsrk6Ble4p/RnGnq3cDLKAgAFR3ACAABgfgIAA1YvQ Date: Wed, 14 Sep 2022 05:16:52 +0000 Message-ID: References: <20220907024020.2474860-1-rongweil@nvidia.com> <1be72d6-be5b-88b2-f15-16fd2c6d0c0@oktetlabs.ru> <5d8d42b2-7011-cb46-7f2c-1b1019c4151e@oktetlabs.ru> In-Reply-To: <5d8d42b2-7011-cb46-7f2c-1b1019c4151e@oktetlabs.ru> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BN9PR12MB5273:EE_|BN9PR12MB5365:EE_ x-ms-office365-filtering-correlation-id: c20a76e4-1208-4185-60e8-08da961055b5 x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VCPwKPK+2KHXiE/XsZcU0fLaRWEIUkjvD8j+atXJg3KDorhg5x6dM2aUv9oR1lmZG+ptRZnMZPSI05VM+TqvxZat54qd2UmM07q9XDAQLgBDU6T5tVL0u5mENZoKaVolaFrEH7HeZGCEUXc9zKEcZ9poPnNhjhD+4WbSWl14DtQ1h9MUoYbiMScKAmqxZj/gVeWhwqwJJHBiWrZ2pH8lOZ0fkZ5zbTditPLgoKDpBdEFf8BYbpQ1ajIjIM1iYgNdfDvbQbMWTR7TV4UsA2mcttCPh8z/WAi+S+055K+8C/upUIaSD/tSPN9JuMG7F+NDYzkem9Mo3vC0JO7646+W51MCKfv10689PCjHfnCAf+v2FxvqhlESV0oaKpyKW4rofovcXmBbkyu0X5lG9ot5X48VC5+QnmOVdtxwDMakxlVkrF6XUd6yvhxs3/calCmqLMIuy19M5bVABg/wimh0FG0NpBB9bHvu0zGav2jxbrWyN3DzM6lkWhdtvAd1vl/YiWHfU49OiDHASxt3jz1ZQnbAW6XRIZhsmUxTteL//55g8Ymqtif4AHDaeoFkOqLe78trlXZvOzdYJ+QU7I1ImfOLV8vpN1zl9ydteGcqoyKxwl5Nnj7bY6TdsV8tAdErQlfeVXeC/5Iy/Uc4toSNHTxD7r3is2O3hZIOiLKuBuV0jVwMWS2GppDKVqkybOCSqPCWAey7xFmsJHYaapKWGWbazN1LEsfY1qSg/vySAP+Ht8HDvnphi97jHKXEX88lH2rAvQ2BdlBIEEoM7upPYw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN9PR12MB5273.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(366004)(346002)(136003)(376002)(396003)(39860400002)(451199015)(66476007)(8676002)(38070700005)(2906002)(55016003)(9686003)(86362001)(41300700001)(53546011)(316002)(107886003)(186003)(8936002)(30864003)(6506007)(66946007)(26005)(64756008)(5660300002)(122000001)(54906003)(83380400001)(478600001)(71200400001)(33656002)(7696005)(4326008)(66556008)(76116006)(66446008)(38100700002)(52536014)(6916009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?rEQXPB5gcn7Z87sShStrlJLDBvPoNMmk1ZjJXsbq3xfLgQGCS8OaVq+dvBhu?= =?us-ascii?Q?/zGOEj3+axYY/w6KloQLmV8TobJ3jUagtYIK16UHC1KUU/sEKzItk8jg/eHx?= =?us-ascii?Q?zcRhQl+tVfESwjwlSu3ozMhMeFRLsPV9m72q5mD9TybOktoM0JzqGQB9di7v?= =?us-ascii?Q?KeGsz0wEO28ZlSYqzIG+SufKTAAnuJieudHsaL9cx5cIL+9WKVIbIMyz8qVW?= =?us-ascii?Q?qxXUo3CO85CQ7totGMzWv+V8im7lr84u49yQshhMjrDnjCfaleZL++61kOFf?= =?us-ascii?Q?sfBkSamWxfL98TTcPCafkH3c/mkRAm3KtVYQTa19Y3/yvRij+tzcs+ER+hJ5?= =?us-ascii?Q?ZgM0pNnppK8hvrNFFP4mnxgQwi9A+a7j4lMN6IAtPUbvMjB2BaD7wXYmMMQR?= =?us-ascii?Q?gKXXj1/OUfdnf8zTF5lZ+h4YUrR8aUqBT2nOYNJnP92nHb4IWxCFHVIyd2Wh?= =?us-ascii?Q?GiQVmKMUEkkoH/bjebbIxZbMmhoUmno/OtNjMhJ5Q85StHSg5LZEOl/R8u1X?= =?us-ascii?Q?xloazo4A+gCVABXPYuf9WS4etckXik2GPBM9ZLh7yi8M1t1QGtRcuRqEfaT0?= =?us-ascii?Q?XOlRAluNnxIdRmCf/L0Rv73AvTrlsS6g9NhjKR/w8J+zJQ48QFQJpvkjsauw?= =?us-ascii?Q?QXfdZOK15AHFWdqWjhGKCnoBZs6c9qvt5G/0LZTlvBCTdWRnJYtQj/ERj2Wt?= =?us-ascii?Q?8OopUlEkxD5JGiiLZlK/uETWozh5VSXia9OOwdVwAOU4/Zs3v8wkPtvi3qhq?= =?us-ascii?Q?nqRWjSj5+WH39cUJcjq+4V8RSt/uJ+sOypxuMX2P9AkoAUyOCIzVebsHLyKW?= =?us-ascii?Q?oX81noGJBrD8HokJtxoysuhPPWDEtpGDwN8LstcrdY6icuKsjiq8jRddlCmJ?= =?us-ascii?Q?4TpoXIhfgUmRjDDDFJcXNm+VCNE56lG2F3eY0xp0ipaL00hrqkEeHeIq0HyA?= =?us-ascii?Q?CqMEC2HZZuUufRpbJZdXwE/lA7Mijzs1Y8Ik0I6pwlYIRZPNA918cQWhIKHN?= =?us-ascii?Q?HwiGXQsn9ogZExr/wbHI0SKABchwn8benatpMS/KmITwzyAadpzRSP/1nGCJ?= =?us-ascii?Q?IMvYcaV9n+HFKVVX2eoL16ohfoCtavSyyeLrdSboOrXB7+yLTbfALBXisjc8?= =?us-ascii?Q?WcGdQtHGcb1dQRNiNjZvnxNKtr7BlCjmLr8svKy7F1jc+EHUhT34lDFegFSE?= =?us-ascii?Q?waE6gEu2Y26lbED/EQZXljmZRC3FWa9Trv3wsIn1sGz4AGEfMVH57HB9FY1H?= =?us-ascii?Q?+6o0tD32a25Fd2/eD06uS8uRbn2iUilGtrQlWVBXUEUEb7U1LkAt14I0F3G0?= =?us-ascii?Q?ppGcqfkbQohD8T7y6DCP8RDjPPAOrfYyhy0u9Oa4aikvEJkftUoP8yR07EIE?= =?us-ascii?Q?weEOWA2mFhEvq6E7SyaxyMflxb8mQIZA8keya/HfuKQ6RIbT65MsA2YUoL5e?= =?us-ascii?Q?lmNYWuGB3ri90esmdHIGkMVrOPeCriNIr3yerGjft+VUhFveB80hvrguh5Mo?= =?us-ascii?Q?GaxMuNHZehZs7QF4tHevRbCNzfTKjJhSd27JkVwZpEDhI4z4MPRvr6KEq8YA?= =?us-ascii?Q?M6ZIeF3xdSVZaYixHSVWEmLBKq4/7Gw4qKkzl2Lz?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN9PR12MB5273.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c20a76e4-1208-4185-60e8-08da961055b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2022 05:16:52.7472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bAJS3Q40aU1lF+qzhaB8q70zz7oP7F5qdHYMaHwcH6do3G40b7kSQP9sJfrE5lHwDAJbEtUfK1zvDsPvgxJveQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR12MB5365 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 BR Rongwei > -----Original Message----- > From: Ivan Malov > Sent: Tuesday, September 13, 2022 22:33 > To: Rongwei Liu > Cc: Matan Azrad ; Slava Ovsiienko > ; Ori Kam ; NBU-Contact- > Thomas Monjalon (EXTERNAL) ; Aman Singh > ; Yuying Zhang ; > Andrew Rybchenko ; dev@dpdk.org; Raslan > Darawsheh > Subject: RE: [PATCH v1] ethdev: add direction info when creating the tran= sfer > table >=20 > External email: Use caution opening links or attachments >=20 >=20 > Hi Rongwei, >=20 > PSB >=20 > On Tue, 13 Sep 2022, Rongwei Liu wrote: >=20 > > Hi > > > > BR > > Rongwei > > > >> -----Original Message----- > >> From: Ivan Malov > >> Sent: Tuesday, September 13, 2022 00:57 > >> To: Rongwei Liu > >> Cc: Matan Azrad ; Slava Ovsiienko > >> ; Ori Kam ; NBU-Contact- > >> Thomas Monjalon (EXTERNAL) ; Aman Singh > >> ; Yuying Zhang ; > >> Andrew Rybchenko ; dev@dpdk.org; > >> Raslan Darawsheh > >> Subject: Re: [PATCH v1] ethdev: add direction info when creating the > >> transfer table > >> > >> External email: Use caution opening links or attachments > >> > >> > >> Hi, > >> > >> On Wed, 7 Sep 2022, Rongwei Liu wrote: > >> > >>> The transfer domain rule is able to match traffic wire/vf origin and > >>> it means two directions' underlayer resource. > >> > >> The point of fact is that matching traffic coming from some entity > >> like wire / VF has been long generalised in the form of representors. > >> So, a flow rule with attribute "transfer" is able to match traffic > >> coming from either a REPRESENTED_PORT or from a PORT_REPRESENTOR > (please find these items). > >> > >>> > >>> In customer deployments, they usually match only one direction > >>> traffic in single flow table: either from wire or from vf. > >> > >> Which customer deployments? Could you please provide detailed examples= ? > >> > >>> > > > > We saw a lot of customers' deployment like: > > 1. Match overlay traffic from wire and do decap, then send to specific = vport. > > 2. Match specific 5-tuples and do encap, then send to wire. > > The matching criteria has obvious direction preference. >=20 > Thank you. My questions are as follows: >=20 > In (1), when you say "from wire", do you mean the need to match packets > arriving via whatever physical ports rather then matching packets arrivin= g > from some specific phys. port? >=20 > If, however, matching traffic "from wire" in fact means matching packets > arriving from a *specific* physical port, then for sure item > REPRESENTED_PORT should perfectly do the job, and the proposed attribute = is > unneeded. >=20 > (BTW, in DPDK, it is customary to use term "physical port", not "wire") >=20 > In (1), what are "vport"s? Please explain. Once again, I should remind th= at, in > DPDK, folks prefer terms "represented entity" / "representor" > over vendor-specific terms like "vport", etc. >=20 Vport is virtual port for short such as VF. > As for (2), imagine matching 5-tuple traffic emitted by a VF / guest. > Could you please explain, why not just add a match item REPRESENTED_PORT > pointing to that VF via its representor? Doing so should perfectly define= the > exact direction / traffic source. Isn't that sufficient? >=20 Per my view, there is matching field and matching value difference. Like IPv4 src_addr 1.1.1.1, 1.1.1.2. 1.1.1.3, will you treat it as same or = different matching criteria? I would like to call them same since it can be summarized like 1.1.1.0/30 REPRESENTED_PORT is just another matching item, no essential differences an= d it can't stand for direction info. Port id depends on the attach sequence. > Also please mind that, although I appreciate your explanations here, on t= he > mailing list, they should finally be added to the commit message, so that > readers do not have to look for them elsewhere. >=20 We have explained the high possibility of single-direction matching, right? It' hard to list all the possibilities of traffic matching preferences. The underlay is the one we have met for now. > > > >>> Introduce one new member transfer_mode into rte_flow_attr to > >>> indicate the flow table direction property: from wire, from vf or > >>> bi-direction(default). > >> > >> AFAIK, 'rte_flow_attr' serves both traditional flow rule insertion > >> and asynchronous (table) approach. The patch adds the attributes to > >> generic 'rte_flow_attr' but, for some reason, ignores non-table rules. > >> > >>> > > Sync API uses one rule to contain everything. It' hard for PMD to deter= mine > if this rule has direction preference or not. > > Image a situation, just for an example: > > 1. Vport 1 VxLAN do decap send to vport 2. 1 million scale > > 2. Vport 0 (wire) VxLAN do decap send to vport 3. 1 hundred scale. > > 1 and 2 share the same matching conditions (eth / ipv4 / udp / vxlan /.= ..), so > sync API consider them share matching determination logic. > > It means "2" have 1M scale capability too. Obviously, it wastes a lot o= f > resources. >=20 > Strictly speaking, they do not share the same match pattern. > Your example clearly shows that, in (1), the pattern should request packe= ts > coming from "vport 1" and, in (2), packets coming from "vport 0". >=20 > My point is simple: the "vport" from which packets enter the embedded swi= tch > is ALSO a match criterion. If you accept this, you'll see: the matching > conditions differ. >=20 See above. In this case, I think the matching fields are both "port_id + ipv4_vxlan". = They are same. Only differs with values like vni 100 or 200 vice versa. > > > > In async API, there is pattern_template introduced. We can mark "1" to = use > pattern_tempate id 1 and "2" to use pattern_template 2. > > They will be separated from each other, don't share anymore. >=20 > Consider an example. "Wire" is a physical port represented by PF0 which, = in > turn, is attached to DPDK via ethdev 0. "VF" (vport?) is attached to gues= t and is > represented by a representor ethdev 1 in DPDK. >=20 > So, some rules (template 1) are needed to deliver packets from "wire" > to "VF" and also decapsulate them. And some rules (template 2) are needed= to > deliver packets in the opposite direction, from "VF" > to "wire" and also encapsulate them. >=20 > My question is, what prevents you from adding match item > REPRESENTED_PORT[ethdev_id=3D0] to the pattern template 1 and > REPRESENTED_PORT[ethdev_id=3D1] to the pattern template 2? >=20 > As I said previously, if you insert such item before eth / ipv4 / etc to = your > match pattern, doing so defines an *exact* direction / source. >=20 Could you check the async API guidance? I think pattern template focusing o= n the matching field (mask). "REPRESENTED_PORT[ethdev_id=3D0] " and "REPRESENTED_PORT[ethdev_id=3D1] "ar= e the same. 1. pattern template: REPRESENTED_PORT mask 0xffff ... 2. action template: action1 / actions2. /=20 3. table create with pattern_template plus action template.. REPRESENTED_PORT[ethdev_id=3D0] will be rule1: rule create REPRESENTED_PO= RT port_id is 0 / actions .... REPRESENTED_PORT[ethdev_id=3D1] will be rule2: rule create REPRESENTED_PO= RT port_id is 1 / actions .... > > > >> For example, the diff below adds the attributes to "table" commands > >> in testpmd but does not add them to regular (non-table) commands like > >> "flow create". Why? > >> > >>> > > > > "table" command limits pattern_template to single direction or bidirect= ion > per user specified attribute. >=20 > As I say above, the same effect can be achieved by adding item > REPRESENTED_PORT to the corresponding pattern template. See above. >=20 > > "rule" command must tight with one "table_id", so the rule will inherit= the > "table" direction property, no need to specify again. >=20 > You migh've misunderstood. I do not talk about "rule" command coupled wit= h > some "table". What I talk about is regular, NON-async flow insertion > commands. >=20 > Please take a look at section "/* Validate/create attributes. */" in file > "app/test-pmd/cmdline_flow.c". When one adds a new flow attribute, they > should reflect it the same way as VC_INGRESS, VC_TRANSFER, etc. >=20 > That's it. We don't intend to pass this to sync API. The above code example is for syn= c API. >=20 > But, as I say, I still believe that the new attributes aren't needed. I think we are not at the same page for now. Can we reach agreement on the = same matching criteria first? > > > >>> It helps to save underlayer memory also on insertion rate. > >> > >> Which memory? Host memory? NIC memory? Term "underlayer" is vague. > >> I suggest that the commit message be revised to first explain how > >> such memory is spent currently, then explain why this is not optimal > >> and, finally, which way the patch is supposed to improve that. I.e. be= more > specific. > >> > >>> > > > > For large scalable rules, HW (depends on implementation) always needs > memory to hold the rules' patterns and actions, either from NIC or from h= ost. > > The memory footprint highly depends on "user rules' complexity", also d= iff > between NICs. > > ~50% memory saving is expected if one-direction is cut. >=20 > Regardless of this talk, this explanation should probably be present in t= he > commit description. > This number may differ with different NICs or implementation. We can't say = it for sure. > > > >>> By default, the transfer domain is bi-direction, and no behavior chan= ges. > >>> > >>> 1. Match wire origin only > >>> flow template_table 0 create group 0 priority 0 transfer wire_orig..= . > >>> 2. Match vf origin only > >>> flow template_table 0 create group 0 priority 0 transfer vf_orig... > >>> > >>> Signed-off-by: Rongwei Liu > >>> --- > >>> app/test-pmd/cmdline_flow.c | 26 ++++++++++++++++++++= + > >>> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 ++- > >>> lib/ethdev/rte_flow.h | 9 ++++++- > >>> 3 files changed, 36 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/app/test-pmd/cmdline_flow.c > >>> b/app/test-pmd/cmdline_flow.c index 7f50028eb7..b25b595e82 100644 > >>> --- a/app/test-pmd/cmdline_flow.c > >>> +++ b/app/test-pmd/cmdline_flow.c > >>> @@ -177,6 +177,8 @@ enum index { > >>> TABLE_INGRESS, > >>> TABLE_EGRESS, > >>> TABLE_TRANSFER, > >>> + TABLE_TRANSFER_WIRE_ORIG, > >>> + TABLE_TRANSFER_VF_ORIG, > >>> TABLE_RULES_NUMBER, > >>> TABLE_PATTERN_TEMPLATE, > >>> TABLE_ACTIONS_TEMPLATE, > >>> @@ -1141,6 +1143,8 @@ static const enum index next_table_attr[] =3D { > >>> TABLE_INGRESS, > >>> TABLE_EGRESS, > >>> TABLE_TRANSFER, > >>> + TABLE_TRANSFER_WIRE_ORIG, > >>> + TABLE_TRANSFER_VF_ORIG, > >>> TABLE_RULES_NUMBER, > >>> TABLE_PATTERN_TEMPLATE, > >>> TABLE_ACTIONS_TEMPLATE, > >>> @@ -2881,6 +2885,18 @@ static const struct token token_list[] =3D { > >>> .next =3D NEXT(next_table_attr), > >>> .call =3D parse_table, > >>> }, > >>> + [TABLE_TRANSFER_WIRE_ORIG] =3D { > >>> + .name =3D "wire_orig", > >>> + .help =3D "affect rule direction to transfer", > >> > >> This does not explain the "wire" aspect. It's too broad. > >> > >>> + .next =3D NEXT(next_table_attr), > >>> + .call =3D parse_table, > >>> + }, > >>> + [TABLE_TRANSFER_VF_ORIG] =3D { > >>> + .name =3D "vf_orig", > >>> + .help =3D "affect rule direction to transfer", > >> > >> This explanation simply duplicates such of the "wire_orig". > >> It does not explain the "vf" part. Should be more specific. > >> > >>> + .next =3D NEXT(next_table_attr), > >>> + .call =3D parse_table, > >>> + }, > >>> [TABLE_RULES_NUMBER] =3D { > >>> .name =3D "rules_number", > >>> .help =3D "number of rules in table", @@ -8894,6 > >>> +8910,16 @@ parse_table(struct context *ctx, const struct token *toke= n, > >>> case TABLE_TRANSFER: > >>> out->args.table.attr.flow_attr.transfer =3D 1; > >>> return len; > >>> + case TABLE_TRANSFER_WIRE_ORIG: > >>> + if (!out->args.table.attr.flow_attr.transfer) > >>> + return -1; > >>> + out->args.table.attr.flow_attr.transfer_mode =3D 1; > >>> + return len; > >>> + case TABLE_TRANSFER_VF_ORIG: > >>> + if (!out->args.table.attr.flow_attr.transfer) > >>> + return -1; > >>> + out->args.table.attr.flow_attr.transfer_mode =3D 2; > >>> + return len; > >>> default: > >>> return -1; > >>> } > >>> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > >>> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > >>> index 330e34427d..603b7988dd 100644 > >>> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > >>> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > >>> @@ -3332,7 +3332,8 @@ It is bound to > >> ``rte_flow_template_table_create()``:: > >>> > >>> flow template_table {port_id} create > >>> [table_id {id}] [group {group_id}] > >>> - [priority {level}] [ingress] [egress] [transfer] > >>> + [priority {level}] [ingress] [egress] > >>> + [transfer [vf_orig] [wire_orig]] > >> > >> Is it correct? Shouldn't it rather be [transfer] [vf_orig] > >> [wire_orig] ? > >> > >>> rules_number {number} > >>> pattern_template {pattern_template_id} > >>> actions_template {actions_template_id} diff --git > >>> a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index > >>> a79f1e7ef0..512b08d817 100644 > >>> --- a/lib/ethdev/rte_flow.h > >>> +++ b/lib/ethdev/rte_flow.h > >>> @@ -130,7 +130,14 @@ struct rte_flow_attr { > >>> * through a suitable port. @see rte_flow_pick_transfer_proxy()= . > >>> */ > >>> uint32_t transfer:1; > >>> - uint32_t reserved:29; /**< Reserved, must be zero. */ > >>> + /** > >>> + * 0 means bidirection, > >>> + * 0x1 origin uplink, > >> > >> What does "uplink" mean? It's too vague. Hardly a good term. > >> > >>> + * 0x2 origin vport, > >> > >> What does "origin vport" mean? Hardly a good term as well. > >> > >>> + * N/A both set. > >> > >> What's this? > >> > >>> + */ > >>> + uint32_t transfer_mode:2; > >>> + uint32_t reserved:27; /**< Reserved, must be zero. */ > >>> }; > >>> > >>> /** > >>> -- > >>> 2.27.0 > >>> > >> > >> Since the attributes are added to generic 'struct rte_flow_attr', > >> non-table > >> (synchronous) flow rules are supposed to support them, too. If that > >> is indeed the case, then I'm afraid such proposal does not agree with > >> the existing items PORT_REPRESENTOR and REPRESENTED_PORT. They do > >> exactly the same thing, but they are designed to be way more generic. = Why > not use them? >=20 > The question stands. >=20 > >> > >> Ivan > > >=20 > Ivan