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 4FF8A43BD7; Tue, 5 Mar 2024 04:04:50 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1C5B440270; Tue, 5 Mar 2024 04:04:50 +0100 (CET) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2074.outbound.protection.outlook.com [40.107.244.74]) by mails.dpdk.org (Postfix) with ESMTP id EF25D4026B for ; Tue, 5 Mar 2024 04:04:47 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iJPcdLtdU+2TmWE0dwz9k9dmYnhwJmEhtCV1nuWeN2mcIaQKn1vWioc5EF4ZCJkETCYizvR+iXkgZ7me9moORKZqTDEDJqMzV8YbTHOUUTaaiNNPUhCR4f4bfwBFQs54T+Adt7T3dKwDO0iZEFN3W9tMcfWgqyC0xk249mGkzFAu6W2GHrFwJFiVHAzw1HzAhnOLslK9dVZ5Q9mYrM43J25uSDQGUwJNcX/dCBd16B8LapzBKD6zkZzizoe0hWJiV8/WN4FBSQ3OUpycvd7JmD50BXE5dTJ0Wehd4DWJ5STgkPhmdQhIXmMXT+7YMESOQs0wV8xFEQJ6vWN8h+31aQ== 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=ejuq2qJZkqFm2ExWGUpl6BR2KEr522KgmqhFKSZvg60=; b=aKO2jwcFWhANEB1eeobyh3g61flJDAhuv55nqdnffYIENpQI+0WKv+6KkjeGFAC9rugf3rNtndyeZVmM0zHovs2Qr95BmVJ9jmng/0/oE5Hr9bBy3pfuTosOiomZ3E1pe42QJPJ+pfOe7zCfK3vSPqruijvvvp2u0cMGfv1abNf3s9F3ACN3+9genAhUGK/t+JIzt5/KFTtr43ooD4Fou02NBsFKUAZ0vTdcTuNJb6QAmyscnuIyNw8sWMkj+Vxyt+tABEnFE892Q67ok+KlbkwAjw+2ea9K1PqsKTj2qKqzmRE8haacmOE1dEUe9ZZv/IFxdcTKHY0TOES219cFRg== 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=ejuq2qJZkqFm2ExWGUpl6BR2KEr522KgmqhFKSZvg60=; b=oUSovl/aOQt0VcQASn+jrnGU72txy6yAYkMmRPTFXWoHbLjSyqEvHQXTKt0e0uRKuScviAqm4r6QyoHYFcwW0IgcyvZKEmlmJmQqo3iAQuktWbo6db3QM0zpQVwoCeucpplBFhVRj1QnIOV/cosVy83vC+BpmVnTIbEDsd3nYUOQjRMvcOO5S79nYou7t/pLTe5IcYcj3OIrpCK1anOEYuVYp9vqcnZmdG1D/Kg1tTY+pMyeItMQOIr/WuLvaTaweLWSXIXWgew7V+g+bkmWD0pLZYwxzNfX19PxVJ2psmM812giR0p8q/MJJq5Psg4PFTgIUWxZ+VW8rQ7WUIN9Ew== Received: from IA1PR12MB6332.namprd12.prod.outlook.com (2603:10b6:208:3e2::13) by SA1PR12MB6947.namprd12.prod.outlook.com (2603:10b6:806:24e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Tue, 5 Mar 2024 03:04:44 +0000 Received: from IA1PR12MB6332.namprd12.prod.outlook.com ([fe80::22fc:4326:d657:92ad]) by IA1PR12MB6332.namprd12.prod.outlook.com ([fe80::22fc:4326:d657:92ad%7]) with mapi id 15.20.7316.012; Tue, 5 Mar 2024 03:04:44 +0000 From: Gregory Etelson To: Ferruh Yigit , "dev@dpdk.org" CC: Maayan Kashani , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Aman Singh , Yuying Zhang , David Marchand Subject: Re: [PATCH v3] testpmd: add hairpin-map parameter Thread-Topic: [PATCH v3] testpmd: add hairpin-map parameter Thread-Index: AQHabAnUgwsreB9Zlku4wrEq1oJYqbEod3hn Date: Tue, 5 Mar 2024 03:04:44 +0000 Message-ID: References: <20230919101006.19936-1-getelson@nvidia.com> <20230928153605.759397-1-getelson@nvidia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: 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: IA1PR12MB6332:EE_|SA1PR12MB6947:EE_ x-ms-office365-filtering-correlation-id: 56424c9e-673f-4e7c-2aee-08dc3cc10219 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: j/VKfQcGglwXVD9XkR7i2SlkeAsMH5wgcKjxsxjihd4cxVIbj/3fp2xvK2qmDSn5nk5NdDS+Iqkgf5P/pR8tjBeck/UmpDw5vCaT7bVV0Dxy6OjUVTuFqGaq4aDJNmUvyrh4jbMdsYQb7ZXGbnrlaQAFOAa1udEz5l6p65pYJ/rPfc50RHIfM9xG/OOIq3FSGIlm0zTDw2/smfQg9TZxKtR36KZIGVAMigKaijVQpbZTZ7ElY8RPuyL/3zpZEqj9GOgx573ml334QMNmn25IIGQWwEAyZjVQeuodC5GrYkvBM+goQT5t6HUAPgXz4RW36rWh9oS+oC1mJt1Kn+/nFxHcv4WWNpRbbVonjzjzi5Oa0LnhZb1D09zfn1/dk4tfFm9zYp1OGiSUR8Y+oZKz0HidqMKRZ+9A5pkrBlOI8ZbsKKy1dJHqt1zpj6m6gc0Cpa8iJdkXu3iOhH8lzNQaKN+BMIZGhQb70tv4sZZhTKgPlVngxorG5VWMXD26olrVk6Css0hSdTv579cyrx9304t5NDPJI3rjL9jQy0f5ZHX83AckrWv0P1B+U9T/+fpNCLa4aRalooAEOtBKrUOjcTMGmZymfdBGiDkSQhGG9u5h0R/nzJ5VGXFt8lr7jEJvX7R7cFistgscfl7K4liB+Ok+Rv4A+zBW5NftYVVZUBCog0RX5hNO7UyZ387uuBC/qEa5DYLlemLgMsjgEeao0bVI72bt/RxgAIghpCpSnA0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:IA1PR12MB6332.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376005)(38070700009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?TkahSp0sbbleFR5WmchKbRvUYMwAliOjKPKQfHBKBRv6xjNE0Z3X9+qtBZ?= =?iso-8859-1?Q?kDgwwI/mm6aE1I3Fkxt+QCI0iih42aenD9uNwIebDcjlTE9iZXCrACNmjm?= =?iso-8859-1?Q?XqhdEI2HxCha9QRBYWvfUZkGHQRnK48cRz5RS4oNFB/1vG93yRsqdZzS/u?= =?iso-8859-1?Q?9EhXBZfhGd8sUJeNkaSQt4O5qHexbAKhszQ0h4+sVSKaOysggs/nMEB3WH?= =?iso-8859-1?Q?XbAvfKjk9jnwv1lwtyftGNfGrPbAo11EWUm7/HSpXyOY/Le45mlnOnHK2I?= =?iso-8859-1?Q?KZuoKMGIcRUVuFL5act7ZsPSRopCvyoJ0RUTN57fE3YVH8lip1A6+X8aut?= =?iso-8859-1?Q?kLjGYKMMoG7GqfPXqBamsnUJhPe4/flQAFBpRxJ9U5yT5Lqm6KxCp3xv/O?= =?iso-8859-1?Q?QxM7YWXw90uF8JwZCW5dao7rb/r0rh/z+2Lm/iwambkWK8JQzSmxyZ0A0Q?= =?iso-8859-1?Q?az/+1AyLZeK4GfqtBo6xLZHCK2YzMr80+tdxHL8ydibKSg51+P5ZaCRQpq?= =?iso-8859-1?Q?2bmW+1ZYMOFOgwatLWrtR3xBCv7jCtUK/TLu66AgywkA3LI5Emd09dUSlg?= =?iso-8859-1?Q?duXssO2OAWb6aF0unkprla9Be/FYheqOluXh/K90HZvZw0qVOwuVbcQKu3?= =?iso-8859-1?Q?03d3mPOKBTyLFfEJiDW3Vws4q9jI54Zf59E30u3+Crt0vkz+QBrb8tji1A?= =?iso-8859-1?Q?T39HlbHsY+wbqkPXdV2G0T+ivJE0v+e2c4Y8HareuAT3EhuD3pOrE4RwbI?= =?iso-8859-1?Q?QSneCHLu3+VAOQgBKW3ZO6/h8lDhx3kAAMF4OeWIMg/bcFWQpn8zjcroNq?= =?iso-8859-1?Q?vp+oYMqU1OGp8+51/5ymSFfm+WaAB9kjtQ7hD/ZtR3IAfVmeaQbhE2OWx0?= =?iso-8859-1?Q?SfuDRJmBgyKyhSTei4mSAN+N3Nt0Uf+DkFdfxlmYmURvY0ZJquxNRWYw5y?= =?iso-8859-1?Q?Y6UPYERe0G+PHPh2Z7eoDQDoL9CnSqOoFGA2T2dAEE6cE0pfOUdQGbaWjz?= =?iso-8859-1?Q?CwNHAMecCJHcYVUtfLtjHNTndHIY06abij0xorWvO/J8x/3hjKZNGbmJNw?= =?iso-8859-1?Q?/JbQxCMTu9EFueY82bWjIIZ2AjX5gQcKVSvh7Bn9p9bU383tdPG/OfrV0c?= =?iso-8859-1?Q?lL2nj3WBKJpOwmU6GgoJ/EDFqfEmZYHQub+hnbg9bYINWrggCngrWiAddR?= =?iso-8859-1?Q?lZJOb3D+DUhjEl2Uvft6uX9HBhrQ7e0sJlwf5l3WPsqLdxP+LKorugMaTd?= =?iso-8859-1?Q?nBVRSQBEYB4kqF2jTxgUEt/5Qf4TW+xm3xC6M3W8fQNZOajWKr4zxHtDzG?= =?iso-8859-1?Q?zYJUKD9e3xEVaHWtf9sYxQxj0lHsGGpT9N4X1yauVvetCsXjyO7uzGKk+V?= =?iso-8859-1?Q?ToIqzT7gVnayq5HvmQHORdfPKNWqNB+bK3Tja5lN0FJzD1irAVUfsQfWur?= =?iso-8859-1?Q?pnSxfPAtGMlrh8mCvlnsufak4R9D57u25qvCe0LfhWx0S6hmn9e5eSqUgT?= =?iso-8859-1?Q?I1NPEFWiFD8zEy98M3adJ4ZiyINEnCZ4T6QvtstcAjT6alm/q81dK0p0eb?= =?iso-8859-1?Q?ReobFbYWTSpS7sSZ6simGeN3x+JIYv+1ExjFhrPlw3p4sKFQfm8nrw8/Ya?= =?iso-8859-1?Q?pRdQQEhZKUOMpwfPCwuG786QKpORZKTu9ilqeGdKvXsuY4Vj6N8/Mb1C60?= =?iso-8859-1?Q?QwXP7Y0uFRymtWw8FzmsuQLDn81tYRszjCVv6O6w?= Content-Type: multipart/alternative; boundary="_000_IA1PR12MB63321EBEDE6160C2F6B4E0AFA5222IA1PR12MB6332namp_" MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB6332.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56424c9e-673f-4e7c-2aee-08dc3cc10219 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2024 03:04:44.1105 (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: 9uWGbIX1zDgua38q80LsDoomhCWBIQ46G8FFmM4X9q+9nV2k6WEroRjGC7XRhUg9n+SeAY9pQk57+RMf51T1yQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6947 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 --_000_IA1PR12MB63321EBEDE6160C2F6B4E0AFA5222IA1PR12MB6332namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Ferruh, As a brainstorm, what do you think move hairpin related code to its own file, and have a kind of register logic to the commands, argument parsing and usage() functions etc. Please consider an option for the testpmd to dynamically add supported comm= ands. Testpmd can still provide some build-in core functionality, but custom test= commands can be added and removed on demand. In addition, the custom command code does not have to be part of the testpm= d. That will reduce maintanance. Regards, Gregory ________________________________ From: Ferruh Yigit Sent: Friday, March 1, 2024 20:54 To: Gregory Etelson ; dev@dpdk.org Cc: Maayan Kashani ; NBU-Contact-Thomas Monjalon (EXTE= RNAL) ; Aman Singh ; Yuying= Zhang ; David Marchand Subject: Re: [PATCH v3] testpmd: add hairpin-map parameter External email: Use caution opening links or attachments On 9/28/2023 4:36 PM, Gregory Etelson wrote: > Hairpin offloads packet forwarding between ports. > Packet is expected on Rx port , Rx queue and is delivered > to Tx port Tx queue . > > Testpmd implements a static hairpin configuration scheme. > The scheme implicitly matches next valid port for given or . > That approach can be used in a single or double port setups only. > > The new parameter allows explicit selection of Rx and Tx ports and > queues in hairpin configuration. > The new `hairpin-map` parameter is provided with 5 parameters, > separated by `:` > > `--hairpin-map=3DRx port id:Rx queue:Tx port id:Tx queue:queues number` > > Testpmd operator can provide several `hairpin-map` parameters for > different hairpin maps. > Example: > > dpdk-testpmd -- \ > \ > --rxq=3D2 --txq=3D2 --hairpinq=3D2 --hairpin-mode=3D0x12 \ > --hairpin-map=3D0:2:1:2:1 \ # [1] > --hairpin-map=3D0:3:2:2:3 # [2] > > Hairpin map [1] binds Rx port 0, queue 2 with Tx port 1, queue 2. > Hairpin map [2] binds > Rx port 0, queue 3 with Tx port 2, queue 2, > Rx port 0, queue 4 with Tx port 2, queue 3, > Rx port 0, queue 5 with Tx port 2, queue 4. > > The new `hairpin-map` parameter is optional. > If omitted, testpmd will create "default" hairpin maps. > Hi Gregory, This patch is waiting for a while in the patchwork, not because there is a problem with the implementation, but I have a feeling that it is bloating the testpmd code with the hairpin feature which is not commonly supported, and I don't know what to do. Also there was no review on the code ... As a brainstorm, what do you think move hairpin related code to its own file, and have a kind of register logic to the commands, argument parsing and usage() functions etc. @David did something similar to move PMD specific testpmd code to the drivers [1]. This can be initial steps for the more modular testpmd design and we can introduce more features with this approach in the future, I think hairpin support is a good instance to start this work, because of its limited impact to users. [1] Commit 592ab76f9f0f ("app/testpmd: register driver specific commands") Commit 94b3c1a72507 ("net/i40e: move testpmd commands") > Signed-off-by: Gregory Etelson > --- > v2: Fix Windows Server 2019 compilation failure. > v3: Update the patch comment. > Fix typo. > --- > app/test-pmd/parameters.c | 63 ++++++++ > app/test-pmd/testpmd.c | 212 ++++++++++++++++++-------- > app/test-pmd/testpmd.h | 18 +++ > doc/guides/testpmd_app_ug/run_app.rst | 3 + > 4 files changed, 230 insertions(+), 66 deletions(-) > > diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c > index a9ca58339d..c6bdfdf06f 100644 > --- a/app/test-pmd/parameters.c > +++ b/app/test-pmd/parameters.c > @@ -206,6 +206,12 @@ usage(char* progname) > printf(" --hairpin-mode=3D0xXX: bitmask set the hairpin port mode.= \n" > " 0x10 - explicit Tx rule, 0x02 - hairpin ports paired\n" > " 0x01 - hairpin ports loop, 0x00 - hairpin port self\n")= ; > + printf(" --hairpin-map=3Drxpi:rxq:txpi:txq:n: hairpin map.\n" > + " rxpi - Rx port index.\n" > + " rxq - Rx queue.\n" > + " txpi - Tx port index.\n" > + " txq - Tx queue.\n" > + " n - hairpin queues number.\n"); > 'rxpi' or 'port index' are not common usage in DPDK, what about 'rx_port' & 'Rx port id' or similar? > } > > #ifdef RTE_LIB_CMDLINE > @@ -588,6 +594,55 @@ parse_link_speed(int n) > return speed; > } > > +static __rte_always_inline > +char *parse_hairpin_map_entry(char *input, char **next) > +{ > Why forcing this function to be inline, can make it static and left decision to compiler. <...> > diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpmd_a= pp_ug/run_app.rst > index 6e9c552e76..a202c98b4c 100644 > --- a/doc/guides/testpmd_app_ug/run_app.rst > +++ b/doc/guides/testpmd_app_ug/run_app.rst > @@ -566,6 +566,9 @@ The command line options are: > > The default value is 0. Hairpin will use single port mode and implic= it Tx flow mode. > > +* ``--hairpin-map=3DRx port id:Rx queue:Tx port id:Tx queue:queues num= ber`` > + > + Set explicit hairpin configuration. > What 'queues number' does is not intuitive, sample in the commit log makes it easier to understand. Can you please either explain or provide sample to clarify what "queues number" is for? --_000_IA1PR12MB63321EBEDE6160C2F6B4E0AFA5222IA1PR12MB6332namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Ferruh,

As a brainstorm, what do you think move hairpin related code to its ownfile, and have a kind of register logic to the commands, argument
parsing and usage() functions etc.

Please consider an option for the testpmd to dyn= amically add supported commands.
Testpmd can still provide some build-in core fun= ctionality, but custom test commands
can be added and removed on demand.
In addition, the custom command code does not have to be part of the testpm= d.
That will reduce maintanance.

Regards,
Gregory

From: Ferruh= Yigit <ferruh.yigit@amd.com>
Sent: Friday, March 1, 2024 20:54
To: Gregory Etelson <getelson@nvidia.com>; dev@dpdk.org &= lt;dev@dpdk.org>
Cc: Maayan Kashani <mkashani@nvidia.com>; NBU-Contact-Tho= mas Monjalon (EXTERNAL) <thomas@monjalon.net>; Aman Singh <aman.de= ep.singh@intel.com>; Yuying Zhang <yuying.zhang@intel.com>; David = Marchand <david.marchand@redhat.com>
Subject: Re: [PATCH v3] testpmd: add hairpin-map parameter
 
External email: Use caution opening l= inks or attachments


On 9/28/2023 4:36 PM, Gregory Etelson wrote:
> Hairpin offloads packet forwarding between ports.
> Packet is expected on Rx port <rp>, Rx queue <rq> and is d= elivered
> to Tx port <tp> Tx queue <tq>.
>
> Testpmd implements a static hairpin configuration scheme.
> The scheme implicitly matches next valid port for given <rp> or = <tp>.
> That approach can be used in a single or double port setups only.
>
> The new parameter allows explicit selection of Rx and Tx ports and
> queues in hairpin configuration.
> The new `hairpin-map` parameter is provided with 5 parameters,
> separated by `:`
>
> `--hairpin-map=3DRx port id:Rx queue:Tx port id:Tx queue:queues number= `
>
> Testpmd operator can provide several `hairpin-map` parameters for
> different hairpin maps.
> Example:
>
> dpdk-testpmd <EAL params> -- \
>   <testpmd params> \
>   --rxq=3D2 --txq=3D2 --hairpinq=3D2 --hairpin-mode=3D0x12 \=
>   --hairpin-map=3D0:2:1:2:1 \ # [1]
>   --hairpin-map=3D0:3:2:2:3   # [2]
>
> Hairpin map [1] binds Rx port 0, queue 2 with Tx port 1, queue 2.
> Hairpin map [2] binds
>   Rx port 0, queue 3 with Tx port 2, queue 2,
>   Rx port 0, queue 4 with Tx port 2, queue 3,
>   Rx port 0, queue 5 with Tx port 2, queue 4.
>
> The new `hairpin-map` parameter is optional.
> If omitted, testpmd will create "default" hairpin maps.
>

Hi Gregory,

This patch is waiting for a while in the patchwork, not because there is a problem with the implementation, but I have a feeling that it is
bloating the testpmd code with the hairpin feature which is not commonly supported, and I don't know what to do.

Also there was no review on the code ...


As a brainstorm, what do you think move hairpin related code to its own
file, and have a kind of register logic to the commands, argument
parsing and usage() functions etc.

@David did something similar to move PMD specific testpmd code to the
drivers [1].

This can be initial steps for the more modular testpmd design and we can introduce more features with this approach in the future, I think
hairpin support is a good instance to start this work, because of its
limited impact to users.


[1]
Commit 592ab76f9f0f ("app/testpmd: register driver specific commands&q= uot;)
Commit 94b3c1a72507 ("net/i40e: move testpmd commands")

> Signed-off-by: Gregory Etelson <getelson@nvidia.com>
> ---
> v2: Fix Windows Server 2019 compilation failure.
> v3: Update the patch comment.
>     Fix typo.
> ---
>  app/test-pmd/parameters.c      &nb= sp;      |  63 ++++++++
>  app/test-pmd/testpmd.c       =          | 212 ++++++++++++++++++--= ------
>  app/test-pmd/testpmd.h       =          |  18 +++
>  doc/guides/testpmd_app_ug/run_app.rst |   3 +
>  4 files changed, 230 insertions(+), 66 deletions(-)
>
> diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
> index a9ca58339d..c6bdfdf06f 100644
> --- a/app/test-pmd/parameters.c
> +++ b/app/test-pmd/parameters.c
> @@ -206,6 +206,12 @@ usage(char* progname)
>       printf("  --hairpin-mode= =3D0xXX: bitmask set the hairpin port mode.\n"
>            = ;  "    0x10 - explicit Tx rule, 0x02 - hairpin po= rts paired\n"
>            = ;  "    0x01 - hairpin ports loop, 0x00 - hairpin = port self\n");
> +     printf("  --hairpin-map=3Drxpi:rxq= :txpi:txq:n: hairpin map.\n"
> +            &q= uot;    rxpi - Rx port index.\n"
> +            &q= uot;    rxq  - Rx queue.\n"
> +            &q= uot;    txpi - Tx port index.\n"
> +            &q= uot;    txq  - Tx queue.\n"
> +            &q= uot;    n    - hairpin queues number.\n"= );
>

'rxpi' or 'port index' are not common usage in DPDK, what about
'rx_port' & 'Rx port id' or similar?

>  }
>
>  #ifdef RTE_LIB_CMDLINE
> @@ -588,6 +594,55 @@ parse_link_speed(int n)
>       return speed;
>  }
>
> +static __rte_always_inline
> +char *parse_hairpin_map_entry(char *input, char **next)
> +{
>

Why forcing this function to be inline, can make it static and left
decision to compiler.

<...>

> diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpm= d_app_ug/run_app.rst
> index 6e9c552e76..a202c98b4c 100644
> --- a/doc/guides/testpmd_app_ug/run_app.rst
> +++ b/doc/guides/testpmd_app_ug/run_app.rst
> @@ -566,6 +566,9 @@ The command line options are:
>
>      The default value is 0. Hairpin will use= single port mode and implicit Tx flow mode.
>
> +*   ``--hairpin-map=3DRx port id:Rx queue:Tx port id:Tx que= ue:queues number``
> +
> +    Set explicit hairpin configuration.
>

What 'queues number' does is not intuitive, sample in the commit log
makes it easier to understand.
Can you please either explain or provide sample to clarify what "queue= s
number" is for?

--_000_IA1PR12MB63321EBEDE6160C2F6B4E0AFA5222IA1PR12MB6332namp_--