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 26BABA00C3; Thu, 3 Feb 2022 17:01:25 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C508440143; Thu, 3 Feb 2022 17:01:24 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id E8CE840140 for ; Thu, 3 Feb 2022 17:01:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643904083; x=1675440083; h=message-id:date:to:cc:references:from:subject: in-reply-to:content-transfer-encoding:mime-version; bh=/K6NcAkLFY22Fhq2z/XeUo6SIHJfo6/ckfcKvOIp6Hg=; b=GX9p8Q9BihkCTMas+A5r2AWwKbfO4Ae8V47IaYd9ZoMh5uR1LYUyxGaD Y8GxW2dRP2XsyY+NU423OP+luxRuRhu6smjGTBwapauTTn5EO6W2WocV7 dBPl+KylxTVN7KWmI5TP+ZN4w+pzAtGQnL1Qjyw59FWhGlqd/fOUqLQ3L heNc2JfnMVdSXNrYvIUolJU1+rYrNzfCJIjd7uer8lLYxmVK9cSevCRBN hbZsohmdZG7zuRODW/5AwLFdHtKRU57Gau7//Q9cofF2/XAAmoEQd6+vU o0XRPjW6nWSvpu9N08OHsRhidBS+Btz0eEaLIWnYB5vhTVTiXfQwUmwoR w==; X-IronPort-AV: E=McAfee;i="6200,9189,10246"; a="228139732" X-IronPort-AV: E=Sophos;i="5.88,340,1635231600"; d="scan'208";a="228139732" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Feb 2022 08:01:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,340,1635231600"; d="scan'208";a="769660454" Received: from orsmsx606.amr.corp.intel.com ([10.22.229.19]) by fmsmga006.fm.intel.com with ESMTP; 03 Feb 2022 08:01:06 -0800 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 3 Feb 2022 08:01:05 -0800 Received: from orsmsx602.amr.corp.intel.com (10.22.229.15) by ORSMSX610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 3 Feb 2022 08:01:05 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20 via Frontend Transport; Thu, 3 Feb 2022 08:01:05 -0800 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.109) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.20; Thu, 3 Feb 2022 08:01:04 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j5jIrtTbipoxYq02/lqV7biwVY9/XDJSENDnYab7QR+jkiyVbSEj53wr1nUz3RgtKxWOr3KQ04GbhJRVMS924GJmAcGBoQnc7zwYxxAsg9ukrEV7QlkSeopdElq4PSDXm1IgX8VXJOtcTP9QxrSpfau+21Hh5wz5/KU0/P/C2yOhycT152E8cr2tOAadf4IHm6OYbl0B9CItOReGLX0mgFgYxOwAVroefXZDKp0oC9DvCH5UM/gytOP5dKtIUlrJCqjNjauW+6REM1reGaW6MtTiHO+Ig27r9gWdxbCVY07FrjapdElfH7Gg15uSztLyOKSY9u3LlQm+oBZlcQmJoA== 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=qkhMLHPzcuiPHSZ9JvdkA3rr6+ajE1rizJmLtWIKEsQ=; b=kQNgBSJ8V0YZhxits8+Q7YXw6UaeMqylWPtvd5OThkk/vf6rEoOw/WNuWoulivmW63BOirSgyBrbJvLbFJrAkG5Uavtcapxc3WW9DI+7pvF1tkrRPIjONJK9RCUnKP32BJJy2fMi5cMEwcVJb3kYepMoiPSu5E2bsmFQhHKRdkd1/b7eHu3eEElL8X56p1F4Ge8CRHgdtqkaowkov6RGvT0pbwp9ohfsCoIl3ICjJ/HDtKrE98HfvK6mwdxLNWkth37IVUhmGo+Nw3OeH/SPzQvbVKPshZUUIl5yhAXu5OfeMs+FeQMvHN7Fo0zogiu6eU1KkXv+WqnLBMjhxNe0qA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by CY4PR11MB1477.namprd11.prod.outlook.com (2603:10b6:910:b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.20; Thu, 3 Feb 2022 16:00:52 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::5046:8550:928d:850e]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::5046:8550:928d:850e%7]) with mapi id 15.20.4951.012; Thu, 3 Feb 2022 16:00:52 +0000 Message-ID: Date: Thu, 3 Feb 2022 16:00:33 +0000 Content-Language: en-US To: , , Thomas Monjalon , Andrew Rybchenko , "Ray Kinsella" CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <20220113102718.3167282-1-jerinj@marvell.com> <20220131180859.2662034-1-jerinj@marvell.com> From: Ferruh Yigit Subject: Re: [dpdk-dev] [PATCH v3 1/2] ethdev: support queue-based priority flow control X-User: ferruhy In-Reply-To: <20220131180859.2662034-1-jerinj@marvell.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0122.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::14) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7024e109-a6a8-430e-fbc9-08d9e72e59f0 X-MS-TrafficTypeDiagnostic: CY4PR11MB1477:EE_ X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9F02nqYSPY76xcAPOc4GGIJjVvsPAvl5QfTYUiflMvtt6TAJUKz8+fNL50rHhmC/CkAsH9zjWfMJd5bPrEs9ZVrpccYfsBRxRiSRpicIjQu6gNaPEB8kb2YcGI1EYYI7fZJTE1pGrhIHrMeN+G8ezLMQMGG6QL7k1mUmaPVXMecQxF3FuhM+9NAABH6VgfGox3BqMTANL7xpWHyo1SZlQbyCojaEPvkN+X5nf5K57nOCvM46rbz6dtZKWa+f0nXZ2G/WH+lpcMZVc6Ap06Uaq0ghFg3QeQ0VFPD6oShAeIk73amihmQMRTyiNcjZVAh/9H6KIf+rtddOkhfCWnMqVlUENgIr5GSufBZBWbRnfFC123KbYek1IOuZ9ofRVHJ3mqOymPiALjTNxfeyDWWwUyp3uS0soIGroXh2S97E+miIuGR1JIRF+TTeGqI3d0fg6wLNpTdhR18OAEufTRLCtk1I2PBj7kOnn81F9aDycNch+N+rVEy6zYPsZdqHyZElKsKTW5bhLatSI/jKNtO+H0ceu0CXGlCjV5JmMvsJBy2yBgvPxkwuNnUtreTH11F9TLJkgqQez9WaiMCBK+uDcQq83n3QM7iti1IThBIvAtdoOSTM1+4yxd+3jTnYpTNeCLFPGNB3ymVGP28SdY81druCE1BXpJbqu4nuEbAu/599rXCc1OLPV0+mL4rX/FzGtFpyeuVCX2Q2dhb7pCv6xiwlCh6OXMNctA7nS0FCj3TKcMRSlUD5kyNaxRJ24wpsCCdv21xUEMWKfzfDMJIGKyhKrHDDifV/Nmsy7triHcA= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(2906002)(31686004)(83380400001)(26005)(2616005)(186003)(82960400001)(86362001)(44832011)(7416002)(55236004)(966005)(6666004)(30864003)(36756003)(7406005)(4326008)(6486002)(66946007)(6506007)(6512007)(66556008)(8676002)(8936002)(110136005)(508600001)(316002)(66476007)(53546011)(31696002)(7366002)(5660300002)(38100700002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Y0toeWNzd2FYR0F4R1E4RUcxSEdsM085SUs5dW15SWJKV3JjZ1NEN3NuMWZB?= =?utf-8?B?MHV3UG85YWtncnFoa3hBbUp2dkQrdmZnMU5SajRkbll4dTVBZjV6aDhCY2xu?= =?utf-8?B?LzcvSURSbXBBa3B1S25uMTZ5MW0rZ3d0THFyc0Nqa0tPSHFSUTlucTBBbUlL?= =?utf-8?B?TzFGUTA0L2RBM2puaGJTRVJncDBZY3FKbjFHam5wZVY1OWVKdTVBMExXWHB0?= =?utf-8?B?VVR0RHBCelpLY1YwTGQzRzdFOVRBQjVoTzZ1d1pWUmNTUm41YVQxdXNDWEk1?= =?utf-8?B?dGZQRE9xN3puRWYrZXdPNVZrb3RybTR3dUpHZ0JKOUhIY2N3V1gyZUpVVFNR?= =?utf-8?B?WDUveTRDcmwrWUJHUXdjOUhpeWlITlZZWVpxMXB2M09pbnFzNVRVSVkreDFR?= =?utf-8?B?YWIvaGhZZmxwMVhVek8vZlltYjAzWEhsNElsT3RuQmNDMWc3SzhMeDlZSEFG?= =?utf-8?B?S3NZeXlnNHc4QWJzMTY2aHZFMVU4L01Wejg5TUJjMWtjOVpTU0FaRVNOcmsw?= =?utf-8?B?dHBKR2s1MExXQUl0RVVrakpvUEZ5bSsya1UzTWw2eTY4L1htQUdTd2JQSjdI?= =?utf-8?B?Vy8vTW10R3JBTnd5R3JpbFZ1TlRUenE2cU9YT0xlN2MxRUdPQWQybzk5bTZW?= =?utf-8?B?aUFmWXV5YkpJVUVCNEQ0cWNyVFIzT0xwYkcwK2ZiaU9uVGI0eUJwWktXYjdT?= =?utf-8?B?Wm5vMWk1a1hNVnlVdndHK3ByNFpkRFBNcm11NlUxbVRkZ3VvQkZTVHAreEtB?= =?utf-8?B?dU92dFdxUGd2TzkwWlZmeTgrdFdzb1pjOEUrMGx2cVNyTGpuZDBYS2hoeHoy?= =?utf-8?B?MVYzS2FMNys5TGlCZnI1eHF0bS9vcnhvSEVyNVZjclRPTVFZcm9PZTZ6V2Jo?= =?utf-8?B?SFlUMXU0RFJaS0g1MWZWVUhqVG5ZK050a0lDdnAyZm1jVHBWWjBSdHBCR25q?= =?utf-8?B?ZUdqWlJ6TEJXMlBnenJlOEh5WUlGaTBKdUdtSEhYa2FITFduazNMTCt1VEJr?= =?utf-8?B?U09kYnJzUXVuNkVvMjQ1bG1BbTZER1ZYSjJWTGtuODlmRjlXL0xucXRIaVE2?= =?utf-8?B?YVlOWVdtTlJXWGh6ekxZQVMxN2lqOTA1YXFXU1hUQnhqRUViL0dxSityeEhC?= =?utf-8?B?b3VucWI2NHlmb21nSWt3bWpUVUZkS0cyMEROblAyT25nOUpIRStWVDd1Z0ln?= =?utf-8?B?MGhjNWQzSzJZOEtqSEJvUmF6SXhDNU1TeEJQc0NiSmVuOGtmVGJXS0tRREpZ?= =?utf-8?B?LzllZWdCeEdWVUdTM3hoaTBqUEhSK1Z0U3dTQmQzSmFWRnhvWExDTDVLcVFk?= =?utf-8?B?alpDUG1FME4vTEowQnZpNG5KOWx3MjN4cGNuaC9vT3d4cnNxY3RMcXNRYUhy?= =?utf-8?B?UVRCazhjQ0xXZ1ZYS1BIcEh2YkZxQzRHNTQ1OVIvK2pCejdsamNScDJYMGk3?= =?utf-8?B?VEw2NTJxQ0dlZXM3MmpXRzJyZk9IWXdkZ1lBYUtmaS9qYlFxaEU4RVBQdlBj?= =?utf-8?B?TzBSZCt2eEhtamo3dk1ZVnN3QmR6bUQ3QzhpTC9nSWdtZVBmSzRBZllXeldj?= =?utf-8?B?NDYvM0FjREtiN29kdlV5TTREdXhVdWFWN1FrTFNZNk4xaWdvOUJTcFZRb0gr?= =?utf-8?B?R1BpOUd0MmY4c1o0WGZya085YlQ0VHhMcUxSTi9WLzMxbWdLVWxwV0NCQUN6?= =?utf-8?B?eDFyMXdOSzgvc3VraFRUejRMQ1BJeDZCTXBWd29SMk5FL2xGb3RBNE1GVncy?= =?utf-8?B?R0NxVXltSTQzdlRUZmhtYmwwQ0duSHhKSlViS0F4NHM1UGtmL0lzSVdjM24x?= =?utf-8?B?bnJTeEU5cnljU1JraFNDUFJFWVJpek5jSGxwOWZwWk9FUEVTZGNkWEk4WUtX?= =?utf-8?B?VC82SEtIb1F3OGtaazJ4V2F3aXpxNDNFc2thYUI1eW1Lemo0Y0ZqcXdvSkRY?= =?utf-8?B?NmZIem5idkc5UndURStZYTE5cGUwTG52Q3lTTzZ5QVpFT2JZOWVQRmFIYlNZ?= =?utf-8?B?ZUhPSmt1NnI4NnJyeTJQeWVRZUVHT3A0cmdSZHduVXZrTHlwU0ZiSm9NbzVL?= =?utf-8?B?azliWldZYXJPY1lPdFBhMlFZenpwZVcvRGZmdDA0QkZHcDFGZks4Q1A3bis2?= =?utf-8?B?dk1hMnRFWW4yT3dEdmw4N3hnSm5ScFd4cHljMTdtSHM0SS9RNzRRMmErQ3BD?= =?utf-8?Q?nYGfmC/7W9f7IVMJx0BqKpM=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 7024e109-a6a8-430e-fbc9-08d9e72e59f0 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2022 16:00:51.8112 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: BKVWsPbOGj9YfvZuVGSL+BZdgmWqy+bOoyaZ1f7nsbL2/Cy8BH7FuEo+eIWoi/wBujok/e1JYrTh9pnowaQq6A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1477 X-OriginatorOrg: intel.com 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 On 1/31/2022 6:08 PM, jerinj@marvell.com wrote: > From: Jerin Jacob > > Based on device support and use-case need, there are two different ways > to enable PFC. The first case is the port level PFC configuration, in > this case, rte_eth_dev_priority_flow_ctrl_set() API shall be used to > configure the PFC, and PFC frames will be generated using based on VLAN > TC value. > > The second case is the queue level PFC configuration, in this > case, Any packet field content can be used to steer the packet to the > specific queue using rte_flow or RSS and then use > rte_eth_dev_priority_flow_ctrl_queue_configure() to configure the > TC mapping on each queue. > Based on congestion selected on the specific queue, configured TC > shall be used to generate PFC frames. > Hi Jerin, Sunil, Please find below minor comments, mostly syntax issues. > Signed-off-by: Jerin Jacob > Signed-off-by: Sunil Kumar Kori > --- > > v2..v1: > - Introduce rte_eth_dev_priority_flow_ctrl_queue_info_get() to > avoid updates to rte_eth_dev_info > - Removed devtools/libabigail.abignore changes > - Address the comment from Ferruh in > http://patches.dpdk.org/project/dpdk/patch/20220113102718.3167282-1-jerinj@marvell.com/ > > doc/guides/nics/features.rst | 7 +- > doc/guides/rel_notes/release_22_03.rst | 6 ++ > lib/ethdev/ethdev_driver.h | 12 ++- > lib/ethdev/rte_ethdev.c | 132 +++++++++++++++++++++++++ > lib/ethdev/rte_ethdev.h | 89 +++++++++++++++++ > lib/ethdev/version.map | 4 + > 6 files changed, 247 insertions(+), 3 deletions(-) > > diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst > index 27be2d2576..1cacdc883a 100644 > --- a/doc/guides/nics/features.rst > +++ b/doc/guides/nics/features.rst > @@ -379,9 +379,12 @@ Flow control > Supports configuring link flow control. > > * **[implements] eth_dev_ops**: ``flow_ctrl_get``, ``flow_ctrl_set``, > - ``priority_flow_ctrl_set``. > + ``priority_flow_ctrl_set``, ``priority_flow_ctrl_queue_info_get``, > + ``priority_flow_ctrl_queue_configure`` > * **[related] API**: ``rte_eth_dev_flow_ctrl_get()``, ``rte_eth_dev_flow_ctrl_set()``, > - ``rte_eth_dev_priority_flow_ctrl_set()``. > + ``rte_eth_dev_priority_flow_ctrl_set()``, > + ``rte_eth_dev_priority_flow_ctrl_queue_info_get()``, > + ``rte_eth_dev_priority_flow_ctrl_queue_configure()``. > > > .. _nic_features_rate_limitation: > diff --git a/doc/guides/rel_notes/release_22_03.rst b/doc/guides/rel_notes/release_22_03.rst > index 3bc0630c7c..e988c104e8 100644 > --- a/doc/guides/rel_notes/release_22_03.rst > +++ b/doc/guides/rel_notes/release_22_03.rst > @@ -69,6 +69,12 @@ New Features > > The new API ``rte_event_eth_rx_adapter_event_port_get()`` was added. > > +* **Added an API to enable queue based priority flow ctrl(PFC).** > + > + New APIs, ``rte_eth_dev_priority_flow_ctrl_queue_info_get()`` and > + ``rte_eth_dev_priority_flow_ctrl_queue_configure()``, was added. > + > + > Can you please move this update before ethdev driver updates. And no need double empty lines. > Removed Items > ------------- > diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h > index d95605a355..320a364766 100644 > --- a/lib/ethdev/ethdev_driver.h > +++ b/lib/ethdev/ethdev_driver.h > @@ -533,6 +533,13 @@ typedef int (*flow_ctrl_set_t)(struct rte_eth_dev *dev, > typedef int (*priority_flow_ctrl_set_t)(struct rte_eth_dev *dev, > struct rte_eth_pfc_conf *pfc_conf); > > +/** @internal Get info for queue based PFC on an Ethernet device. */ > +typedef int (*priority_flow_ctrl_queue_info_get_t)( > + struct rte_eth_dev *dev, struct rte_eth_pfc_queue_info *pfc_queue_info); > +/** @internal Configure queue based PFC parameter on an Ethernet device. */ > +typedef int (*priority_flow_ctrl_queue_config_t)( > + struct rte_eth_dev *dev, struct rte_eth_pfc_queue_conf *pfc_queue_conf); > + Instead of ending line with opening parantesis '(', can you break the line after first argument, like: typedef int (*priority_flow_ctrl_queue_config_t)(struct rte_eth_dev *dev, struct rte_eth_pfc_queue_conf *pfc_queue_conf); Same for all instances. > /** @internal Update RSS redirection table on an Ethernet device. */ > typedef int (*reta_update_t)(struct rte_eth_dev *dev, > struct rte_eth_rss_reta_entry64 *reta_conf, > @@ -1080,7 +1087,10 @@ struct eth_dev_ops { > flow_ctrl_set_t flow_ctrl_set; /**< Setup flow control */ > /** Setup priority flow control */ > priority_flow_ctrl_set_t priority_flow_ctrl_set; > - > + /** Priority flow control queue info get */ > + priority_flow_ctrl_queue_info_get_t priority_flow_ctrl_queue_info_get; > + /** Priority flow control queue configure */ > + priority_flow_ctrl_queue_config_t priority_flow_ctrl_queue_config; Can you please keep empty line before next (hash) group? > /** Set Unicast Table Array */ > eth_uc_hash_table_set_t uc_hash_table_set; > /** Set Unicast hash bitmap */ > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c > index a1d475a292..2ce38cd2c5 100644 > --- a/lib/ethdev/rte_ethdev.c > +++ b/lib/ethdev/rte_ethdev.c > @@ -4022,6 +4022,138 @@ rte_eth_dev_priority_flow_ctrl_set(uint16_t port_id, > return -ENOTSUP; > } > > +static inline int Not sure if there is a value to ask function to be 'inline', this is in control path, only static can be enough. > +validate_rx_pause_config(struct rte_eth_dev_info *dev_info, uint8_t tc_max, > + struct rte_eth_pfc_queue_conf *pfc_queue_conf) > +{ > + if ((pfc_queue_conf->mode == RTE_ETH_FC_RX_PAUSE) || > + (pfc_queue_conf->mode == RTE_ETH_FC_FULL)) { We don't allign to paranthesis in dpdk coding convenion [1], it should be as: if ((pfc_queue_conf->mode == RTE_ETH_FC_RX_PAUSE) || (pfc_queue_conf->mode == RTE_ETH_FC_FULL)) { if (pfc_queue_conf->rx_pause.tx_qid >= dev_info->nb_tx_queues) { ... } } [1] Altough I am aware many instances sneaked in, still I think better to follow the convention. > + if (pfc_queue_conf->rx_pause.tx_qid >= dev_info->nb_tx_queues) { > + RTE_ETHDEV_LOG(ERR, "Tx queue not in range for Rx pause" > + " (requested: %d configured: %d)\n", > + pfc_queue_conf->rx_pause.tx_qid, > + dev_info->nb_tx_queues); Should log mention that this is related to the "priority flow Rx queue control"? > + return -EINVAL; > + } > + > + if (pfc_queue_conf->rx_pause.tc >= tc_max) { Should we document somewhere that 'tc_max' value itself is an invalid value? > + RTE_ETHDEV_LOG(ERR, "TC not in range for Rx pause" > + " (requested: %d max: %d)\n", > + pfc_queue_conf->rx_pause.tc, tc_max); > + return -EINVAL; > + } > + } > + > + return 0; > +} > + > +static inline int > +validate_tx_pause_config(struct rte_eth_dev_info *dev_info, uint8_t tc_max, > + struct rte_eth_pfc_queue_conf *pfc_queue_conf) > +{ > + if ((pfc_queue_conf->mode == RTE_ETH_FC_TX_PAUSE) || > + (pfc_queue_conf->mode == RTE_ETH_FC_FULL)) { > + if (pfc_queue_conf->tx_pause.rx_qid >= dev_info->nb_rx_queues) { > + RTE_ETHDEV_LOG(ERR, "Rx queue not in range for Tx pause" > + "(requested: %d configured: %d)\n", > + pfc_queue_conf->tx_pause.rx_qid, > + dev_info->nb_rx_queues); > + return -EINVAL; > + } > + > + if (pfc_queue_conf->tx_pause.tc >= tc_max) { > + RTE_ETHDEV_LOG(ERR, "TC not in range for Tx pause" > + "(requested: %d max: %d)\n", > + pfc_queue_conf->tx_pause.tc, tc_max); > + return -EINVAL; > + } > + } > + > + return 0; > +} > + > +int > +rte_eth_dev_priority_flow_ctrl_queue_info_get( > + uint16_t port_id, struct rte_eth_pfc_queue_info *pfc_queue_info) > +{ > + struct rte_eth_dev *dev; > + > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV); > + dev = &rte_eth_devices[port_id]; > + > + if (pfc_queue_info == NULL) { > + RTE_ETHDEV_LOG(ERR, "PFC info param is NULL for port (%u)\n", > + port_id); > + return -EINVAL; > + } > + > + if (*dev->dev_ops->priority_flow_ctrl_queue_info_get) > + return eth_err(port_id, > + (*dev->dev_ops->priority_flow_ctrl_queue_info_get)( > + dev, pfc_queue_info)); > + return -ENOTSUP; > +} > + > +int > +rte_eth_dev_priority_flow_ctrl_queue_configure( > + uint16_t port_id, struct rte_eth_pfc_queue_conf *pfc_queue_conf) > +{ > + struct rte_eth_pfc_queue_info pfc_info; > + struct rte_eth_dev_info dev_info; > + struct rte_eth_dev *dev; > + int ret; > + > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV); > + dev = &rte_eth_devices[port_id]; > + > + if (pfc_queue_conf == NULL) { > + RTE_ETHDEV_LOG(ERR, "PFC parameters are NULL for port (%u)\n", > + port_id); > + return -EINVAL; > + } > + > + ret = rte_eth_dev_info_get(port_id, &dev_info); > + if (ret != 0) > + return ret; > + > + ret = rte_eth_dev_priority_flow_ctrl_queue_info_get(port_id, &pfc_info); > + if (ret != 0) > + return ret; > + > + if (pfc_info.capa == 0) { > + RTE_ETHDEV_LOG(ERR, "Ethdev port %u does not support PFC\n", > + port_id); > + return -ENOTSUP; > + } > + > + if (pfc_info.tc_max == 0) { > + RTE_ETHDEV_LOG(ERR, > + "Ethdev port %u does not support PFC TC values\n", > + port_id); > + return -ENOTSUP; > + } > + > + if (pfc_info.capa & RTE_ETH_PFC_QUEUE_CAPA_RX_PAUSE) { > + ret = validate_rx_pause_config(&dev_info, pfc_info.tc_max, > + pfc_queue_conf); There is capablilty flags for RTE_ETH_PFC_QUEUE_CAPA_RX_PAUSE and RTE_ETH_PFC_QUEUE_CAPA_TX_PAUSE also there is config flags RTE_ETH_FC_RX_PAUSE, RTE_ETH_FC_TX_PAUSE and RTE_ETH_FC_FULL What should happen if driver only support RX_PAUSE but app config request only TX_PAUSE? As far as can see with current code it pass the validation, but should it? > + if (ret != 0) > + return ret; > + } > + > + if (pfc_info.capa & RTE_ETH_PFC_QUEUE_CAPA_TX_PAUSE) { > + ret = validate_tx_pause_config(&dev_info, pfc_info.tc_max, > + pfc_queue_conf); syntax, please don't align to paranthesis > + if (ret != 0) > + return ret; > + } > + > + if (*dev->dev_ops->priority_flow_ctrl_queue_config) > + return eth_err(port_id, > + (*dev->dev_ops->priority_flow_ctrl_queue_config)( > + dev, pfc_queue_conf)); > + return -ENOTSUP; > +} > + > static int > eth_check_reta_mask(struct rte_eth_rss_reta_entry64 *reta_conf, > uint16_t reta_size) > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h > index fa299c8ad7..383ad1cdd7 100644 > --- a/lib/ethdev/rte_ethdev.h > +++ b/lib/ethdev/rte_ethdev.h > @@ -1395,6 +1395,48 @@ struct rte_eth_pfc_conf { > uint8_t priority; /**< VLAN User Priority. */ > }; > > +/** Device supports Rx pause for queue based PFC. */ > +#define RTE_ETH_PFC_QUEUE_CAPA_RX_PAUSE RTE_BIT64(0) > +/** Device supports Tx pause for queue based PFC. */ > +#define RTE_ETH_PFC_QUEUE_CAPA_TX_PAUSE RTE_BIT64(1) > + There is already control flow mode enum 'enum rte_eth_fc_mode', those enum items use FC as abrivation (RTE_ETH_FC_RX_PAUSE), above ones use PFC, should they use same prefix 'RTE_ETH_FC_' for consistency? And overall, what for struct and functins too, is the correct abreviation 'pfc' or 'fc', since old code has 'fc' as far as I see? > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice > + * > + * A structure used to retrieve information of queue based PFC. > + */ > +struct rte_eth_pfc_queue_info { > + /** > + * Maximum supported traffic class as per PFC (802.1Qbb) specification. Will it be redundant to say valid value should be bigger than 0? > + */ > + uint8_t tc_max; > + /** PFC queue capabilities (RTE_ETH_PFC_QUEUE_CAPA_). */ Can move doxygen comments to same line if they fit to 80 char limit: uint64_t capa; /**< PFC queue capabilities (RTE_ETH_PFC_QUEUE_CAPA_). */ > + uint64_t capa; > +}; > + > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change, or be removed, without prior notice > + * > + * A structure used to configure Ethernet priority flow control parameter for > + * ethdev queues. > + */ > +struct rte_eth_pfc_queue_conf { > + enum rte_eth_fc_mode mode; /**< Link flow control mode */ > + > + struct { > + uint16_t tx_qid; /**< Tx queue ID */ 'tx_qid' within 'rx_pause' struct, this seems done intentionally but just to double check, can you please describe here the intendent usage? > + uint8_t tc; /**< Traffic class as per PFC (802.1Qbb) spec */ > + } rx_pause; /* Valid when (mode == FC_RX_PAUSE || mode == FC_FULL) */ > + > + struct { > + uint16_t pause_time; /**< Pause quota in the Pause frame */ > + uint16_t rx_qid; /**< Rx queue ID */ > + uint8_t tc; /**< Traffic class as per PFC (802.1Qbb) spec */ > + } tx_pause; /* Valid when (mode == FC_TX_PAUSE || mode == FC_FULL) */ > +}; > + > /** > * Tunnel type for device-specific classifier configuration. > * @see rte_eth_udp_tunnel > @@ -4144,6 +4186,53 @@ int rte_eth_dev_priority_flow_ctrl_set(uint16_t port_id, > int rte_eth_dev_mac_addr_add(uint16_t port_id, struct rte_ether_addr *mac_addr, > uint32_t pool); > > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice. > + * > + * Retrieve the information for queue based PFC. > + * > + * @param port_id > + * The port identifier of the Ethernet device. > + * @param pfc_queue_info > + * A pointer to a structure of type *rte_eth_pfc_queue_info* to be filled with > + * the information about queue based PFC. > + * @return > + * - (0) if successful. > + * - (-ENOTSUP) if support for priority_flow_ctrl_queue_info_get does not exist. > + * - (-ENODEV) if *port_id* invalid. > + * - (-EINVAL) if bad parameter. > + */ > +__rte_experimental > +int rte_eth_dev_priority_flow_ctrl_queue_info_get(uint16_t port_id, > + struct rte_eth_pfc_queue_info *pfc_queue_info); > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice. > + * > + * Configure the queue based priority flow control for a given queue > + * for Ethernet device. > + * > + * @note When an ethdev port switches to queue based PFC mode, the > + * unconfigured queues shall be configured by the driver with > + * default values such as lower priority value for TC etc. > + * May be good to document it has dependency to 'rte_eth_dev_info_get()' API? > + * @param port_id > + * The port identifier of the Ethernet device. > + * @param pfc_queue_conf > + * The pointer to the structure of the priority flow control parameters > + * for the queue. > + * @return > + * - (0) if successful. > + * - (-ENOTSUP) if hardware doesn't support queue based PFC mode. > + * - (-ENODEV) if *port_id* invalid. > + * - (-EINVAL) if bad parameter > + * - (-EIO) if flow control setup queue failure > + */ > +__rte_experimental > +int rte_eth_dev_priority_flow_ctrl_queue_configure(uint16_t port_id, > + struct rte_eth_pfc_queue_conf *pfc_queue_conf); > + > /** > * Remove a MAC address from the internal array of addresses. > * > diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map > index c2fb0669a4..49523ebc45 100644 > --- a/lib/ethdev/version.map > +++ b/lib/ethdev/version.map > @@ -256,6 +256,10 @@ EXPERIMENTAL { > rte_flow_flex_item_create; > rte_flow_flex_item_release; > rte_flow_pick_transfer_proxy; > + > + # added in 22.03 > + rte_eth_dev_priority_flow_ctrl_queue_configure; > + rte_eth_dev_priority_flow_ctrl_queue_info_get; > }; > > INTERNAL {