From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <f113fd33-8049-8aec-d345-ac834ea1a5ac@intel.com>
Date: Thu, 3 Feb 2022 16:00:33 +0000
Content-Language: en-US
To: <jerinj@marvell.com>, <dev@dpdk.org>, Thomas Monjalon
 <thomas@monjalon.net>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, "Ray
 Kinsella" <mdr@ashroe.eu>
CC: <ajit.khaparde@broadcom.com>, <aboyer@pensando.io>,
 <beilei.xing@intel.com>, <bruce.richardson@intel.com>, <chas3@att.com>,
 <chenbo.xia@intel.com>, <ciara.loftus@intel.com>, <dsinghrawat@marvell.com>,
 <ed.czeck@atomicrules.com>, <evgenys@amazon.com>, <grive@u256.net>,
 <g.singh@nxp.com>, <zhouguoyang@huawei.com>, <haiyue.wang@intel.com>,
 <hkalra@marvell.com>, <heinrich.kuhn@corigine.com>, <hemant.agrawal@nxp.com>, 
 <hyonkim@cisco.com>, <igorch@amazon.com>, <irusskikh@marvell.com>,
 <jgrajcia@cisco.com>, <jasvinder.singh@intel.com>, <jianwang@trustnetic.com>, 
 <jiawenwu@trustnetic.com>, <jingjing.wu@intel.com>, <johndale@cisco.com>,
 <john.miller@atomicrules.com>, <linville@tuxdriver.com>,
 <keith.wiles@intel.com>, <kirankumark@marvell.com>, <oulijun@huawei.com>,
 <lironh@marvell.com>, <longli@microsoft.com>, <mw@semihalf.com>,
 <spinler@cesnet.cz>, <matan@nvidia.com>, <matt.peters@windriver.com>,
 <maxime.coquelin@redhat.com>, <mk@semihalf.com>, <humin29@huawei.com>,
 <pnalla@marvell.com>, <ndabilpuram@marvell.com>, <qiming.yang@intel.com>,
 <qi.z.zhang@intel.com>, <radhac@marvell.com>, <rahul.lakkireddy@chelsio.com>, 
 <rmody@marvell.com>, <rosen.xu@intel.com>, <sachin.saxena@oss.nxp.com>,
 <skoteshwar@marvell.com>, <shshaikh@marvell.com>, <shaibran@amazon.com>,
 <shepard.siegel@atomicrules.com>, <asomalap@amd.com>,
 <somnath.kotur@broadcom.com>, <sthemmin@microsoft.com>,
 <steven.webster@windriver.com>, <skori@marvell.com>, <mtetsuyah@gmail.com>,
 <vburru@marvell.com>, <viacheslavo@nvidia.com>, <xiao.w.wang@intel.com>,
 <cloud.wangxiaoyun@huawei.com>, <yisen.zhuang@huawei.com>,
 <yongwang@vmware.com>, <xuanziyang2@huawei.com>
References: <20220113102718.3167282-1-jerinj@marvell.com>
 <20220131180859.2662034-1-jerinj@marvell.com>
From: Ferruh Yigit <ferruh.yigit@intel.com>
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: <CY4PR11MB14773B17213B177F2320559E95289@CY4PR11MB1477.namprd11.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On 1/31/2022 6:08 PM, jerinj@marvell.com wrote:
> From: Jerin Jacob <jerinj@marvell.com>
> 
> 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 <jerinj@marvell.com>
> Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
> ---
> 
> 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 {