From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D2DE4A04B8; Wed, 2 Sep 2020 12:31:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6FD05137D; Wed, 2 Sep 2020 12:31:12 +0200 (CEST) Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) by dpdk.org (Postfix) with ESMTP id 4ED4C255 for ; Wed, 2 Sep 2020 12:31:10 +0200 (CEST) Received: from hkpgpgate102.nvidia.com (Not Verified[10.18.92.100]) by nat-hk.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Wed, 02 Sep 2020 18:31:09 +0800 Received: from HKMAIL101.nvidia.com ([10.18.16.10]) by hkpgpgate102.nvidia.com (PGP Universal service); Wed, 02 Sep 2020 03:31:09 -0700 X-PGP-Universal: processed; by hkpgpgate102.nvidia.com on Wed, 02 Sep 2020 03:31:09 -0700 Received: from HKMAIL103.nvidia.com (10.18.16.12) by HKMAIL101.nvidia.com (10.18.16.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 2 Sep 2020 10:31:01 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.176) by HKMAIL103.nvidia.com (10.18.16.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 2 Sep 2020 10:31:01 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HkcpUvjU2eciXKXwrw33AbKbjKCFSg+0zwXAs1G0kx2o5Q02EYLzMVqC5C3hIs4iv5Uw1CYiRa8Nr7HjSa5JuxwlV+jyc/m9O7hw5jixHjfxutPa3xHVPqrP5gn0Wi9f3S5AhJx40vvFy1fyELV4IDQLUuk8i0WK537WLPN3xqqsx8sWYnTe0O5F9PUq9SPI7koDvKypA4zlFmwVVnDUmrTl9oYbeSitj4+CtNM9LnEA6Jwy36mSBslguUMZ+sUzxeY/HGS5P16YKSZbyQODj2iISCGriNb5Hb4zsTwTgYtBuxYmRB2uNyX7cX4IaBDqU2dzEfU8BiAH42dZEICwqQ== 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-SenderADCheck; bh=fdhYEj8wjVa3Hpkzan28kgQGTB4AKLEvAswV3fg4UqI=; b=Ta0C3oXCIaShRGXhUqAYXp1HX1aVafGaN8Uw2msOz92Aa6pBT4cGD4XEAR15cfovHdg71OXF1fnJeNl+t4ZF61KqPDkqKeZgwPDXwWVov4Oj1jmhKovH7WsHdXxXBFUCLeVbbw7GTXl0C6z0GpQIphqOPJVm9Isk9A7K9IDBIMi/KOMZ5eCU9LwG3iTpjfgjLOV+JbkicXzS3smxPyS6iugc/CPap/Rb/KEpnVAEURuYfGuWwzGbINMlHbrep0DHEuHKKTPPwPabR/Ksj0+5tZPwqlvfjJIdp7OZgqdxjvZrzvUfBidXAykuLU9+7y0UcysOhgsf3U6TW+OY7YM46g== 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 Received: from MW2PR12MB2492.namprd12.prod.outlook.com (2603:10b6:907:8::19) by MW3PR12MB4476.namprd12.prod.outlook.com (2603:10b6:303:2d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.23; Wed, 2 Sep 2020 10:30:59 +0000 Received: from MW2PR12MB2492.namprd12.prod.outlook.com ([fe80::693f:4ec4:caa9:ac9c]) by MW2PR12MB2492.namprd12.prod.outlook.com ([fe80::693f:4ec4:caa9:ac9c%5]) with mapi id 15.20.3326.025; Wed, 2 Sep 2020 10:30:59 +0000 From: Matan Azrad To: Chengchang Tang , "dev@dpdk.org" CC: "maryam.tahhan@intel.com" , "linuxarm@huawei.com" , "ferruh.yigit@intel.com" , "wenzhuo.lu@intel.com" , NBU-Contact-Thomas Monjalon , "arybchenko@solarflare.com" Thread-Topic: [dpdk-dev] [PATCH v3 1/4] ethdev: add a field for rxq info structure Thread-Index: AQHWfdRddMw/ykWHNkeaRKxv9sXGxqlT7AawgADRJ4CAADaIUIAAMMIAgAAB59A= Date: Wed, 2 Sep 2020 10:30:59 +0000 Message-ID: References: <1592483709-7076-1-git-send-email-tangchengchang@huawei.com> <1598685199-1630-1-git-send-email-tangchengchang@huawei.com> <1598685199-1630-2-git-send-email-tangchengchang@huawei.com> <1a4dc7d6-5596-34cb-9eb1-adcd2adef2fb@huawei.com> In-Reply-To: <1a4dc7d6-5596-34cb-9eb1-adcd2adef2fb@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [77.126.81.41] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9b268cb0-26a0-40e1-3ee3-08d84f2b48d6 x-ms-traffictypediagnostic: MW3PR12MB4476: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Wvz0Qi/G5XHrH2vjsjnxKLc9tIxx39cmNhMauEMHrqQ3YW10h0WYm7iWh3TVq3Oj5g8U+ndYVnnaNpLKUabuFFl5XZU3Y560LI+nkN4HqymYylUTb5ANtIFvGyBhqjrpiMsptH6fSSwtDb2KPe9b3tx6bOE0nWZ1JVezRp5Eqk34GBtQNO8AfWGuag9ncdFD0qpPQKJqU7chKWxQVSEaH5SZCizxnEtYjumO9Q6LqfVnjYGJtByuMHCRaDceGFz8etnGTZLit53LAtFdXjE7SocZh1/Zz0Kx7m8z7iX7DrsmDrE23+dlzyllILdNHj4KkavDUOQ9q+VxjJ+04oamyg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR12MB2492.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(39860400002)(376002)(396003)(366004)(9686003)(4326008)(2906002)(55016002)(478600001)(8936002)(8676002)(33656002)(71200400001)(186003)(76116006)(5660300002)(110136005)(26005)(66476007)(316002)(64756008)(83380400001)(53546011)(66946007)(7696005)(6506007)(66556008)(86362001)(66446008)(52536014)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: sNXQuK+Wp+lN6FJg7YkBVtSjdiGfoA7nCer4r5bsHPiPtRgUPywMDTnUmLXe3jsfboMEhSUCpDQQl9tM44nUC0Ld630uOPyGT4x023KHwFUavhXzOSJ2qoFuDZoHcbdjQx4k9T+htqk4ioSUm+ZeQmSlTZ2uu/YM6GuY4gJxoj4G4fe+YXXTQIQs0PCg5DBSXyJ35oBqAK8ylEOhW3qItS3nSw7xojURhrG+nderdQwuQlv6SXIOyd6YZfQysw1kTCB7hrukR07KFBn8lg9ae2OMZLSRwfsFm3klNdMrvHjNTw2ehgZIpZKWNvinQ/wsD4KQNiGW4OJ9qu6I2+k9piMVmZH14tkmeIJkVe87AImqTPk5dW9v4/nYzWliZSGUb7kTh01ImgV/1ly2XttKl6PzgIL2dD+K2m49txvcx1pOwT/ZJSrNQbuWLJvO3G7Lf6HhP85yhRlNk8alWbh93v67kHN7bVGYOZa20G5AQgpiU1YikUS03gN2nxOHE8E/rmxLIsT8o4I5nkbTVPUjKmDj2jx9ux5CCh9sB96fwNzOk+tmc9oFbT9oxkzDnddZWUYn+aLIpCmxCiEJRz8sER29BWH5asQN/EGnS73W+qKDZaig9VQ4PXiYKFvOo82EWpK6krKpz6PPGzeHQBLL5Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR12MB2492.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9b268cb0-26a0-40e1-3ee3-08d84f2b48d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2020 10:30:59.5654 (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: ujdsaHikuB1v3LKKI8n1ANOW7x1IlVjAOjS4zoNhljFcHqgN/bQzM1BbehGgN+1Qds84KTCi7TP6DDkxq/EueA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4476 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1599042669; bh=fdhYEj8wjVa3Hpkzan28kgQGTB4AKLEvAswV3fg4UqI=; h=X-PGP-Universal:ARC-Seal:ARC-Message-Signature: ARC-Authentication-Results:From:To:CC:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:authentication-results:x-originating-ip: x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-ms-traffictypediagnostic:x-ld-processed: x-microsoft-antispam-prvs:x-ms-oob-tlc-oobclassifiers: x-ms-exchange-senderadcheck:x-microsoft-antispam: x-microsoft-antispam-message-info:x-forefront-antispam-report: x-ms-exchange-antispam-messagedata:x-ms-exchange-transport-forked: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-AuthAs: X-MS-Exchange-CrossTenant-AuthSource: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped:X-OriginatorOrg; b=IzQ0HNsrDhAnqAtqR2VyZUI64ymUzNg3AS7ryzhPXhL9lXIWsokz3YizQbU0jgWU+ YBmyX7kVqvKuaVBIEa1G0ZTMm9SDZFEMiKYXa6vBo2zHyxpXNRIfDmDaat/sCWTway dyU6P6884i5Zpo6FCXYFWX/8W8QOgIkwaA+ULZrCRJYZ7MsuKWljIVgriA/VRfPNfo 1iN+Y5MpbJyly42KpWE+NTHbo0ZRvc3CQwb+1GTs/eFd9LzPqTCMBUikK0c8qBwP0V VpS4+4ZnhB44DARxKuoJHZdvy2xBFohXvFoXx/DrpXlp/2JRJ6cRSzHAPsCzrMZ/a2 78LKYSv2+Y7pA== Subject: Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add a field for rxq info structure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Chengchang From: Chengchang Tang > Hi, Matan >=20 > On 2020/9/2 15:19, Matan Azrad wrote: > > > > Hi Chengchang > > > > From: Chengchang Tang > >> Hi, Matan > >> > >> On 2020/9/1 23:33, Matan Azrad wrote: > >>> > >>> Hi Chengchang > >>> > >>> Please see some question below. > >>> > >>> From: Chengchang Tang > >>>> Add a field named rx_buf_size in rte_eth_rxq_info to indicate the > >>>> buffer size used in receiving packets for HW. > >>>> > >>>> In this way, upper-layer users can get this information by calling > >>>> rte_eth_rx_queue_info_get. > >>>> > >>>> Signed-off-by: Chengchang Tang > >>>> Reviewed-by: Wei Hu (Xavier) > >>>> Acked-by: Andrew Rybchenko > >>>> --- > >>>> lib/librte_ethdev/rte_ethdev.h | 2 ++ > >>>> 1 file changed, 2 insertions(+) > >>>> > >>>> diff --git a/lib/librte_ethdev/rte_ethdev.h > >>>> b/lib/librte_ethdev/rte_ethdev.h index 70295d7..9fed5cb 100644 > >>>> --- a/lib/librte_ethdev/rte_ethdev.h > >>>> +++ b/lib/librte_ethdev/rte_ethdev.h > >>>> @@ -1420,6 +1420,8 @@ struct rte_eth_rxq_info { > >>>> struct rte_eth_rxconf conf; /**< queue config parameters. */ > >>>> uint8_t scattered_rx; /**< scattered packets RX suppor= ted. */ > >>>> uint16_t nb_desc; /**< configured number of RXDs. = */ > >>>> + /**< buffer size used for hardware when receive packets. */ > >>>> + uint16_t rx_buf_size; > >>> > >>> Is it the maximum supported Rx buffer by the HW? > >>> If yes, maybe max_rx_buf_size is better name? > >> > >> No, it is the Rx buffer size currently used by HW. > > Doesn't it defined by the user? Using Rx queue mem-pool mbuf room size? > > > > And it may be different per Rx queue.... >=20 > Yes, it is defined by user using the Rx queue mem-pool mbuf room size. > When different queues are bound to different mempools, different queues > may have different value. > > > >> IMHO, the structure rte_eth_rxq_info and associated query API are > >> mainly used to query HW configurations at runtime or after queue is > >> configured/setup. Therefore, the content of this structure should be > >> the current HW configuration. > > > > It looks me more like capabilities... > > The one which define the current configuration is the user by the > configuration APIs(after reading the capabilities). >=20 > I prefer to consider the structure rte_eth_dev_info as the capabilities. Yes. > Because rxq_info and associated APIs are not available until the queue is > configured. And the max rx_buf_size is already exists in dev_info. > > > > I don't think we have here all the current configurations, so what is s= pecial > in this one? >=20 > I think the structure is used to store the queue-related configuration, > especially the final HW configuration that may be different from user > configuration and some configurations that are not mandatory for the > user(PMDs will use a default configuration). Such as the scatterred_rx an= d > rx_drop_en in rte_eth_rxconf, some PMDs will adjust it in some cases base= d > on their HW constraints. Ok, this struct(struct rte_eth_rxq_info) is new for me. Thanks for the explanation. =20 > This configuration item meets the above criteria. The value range of > rx_buf_size varies according to HW. Some HW may require 1k-alignment, > while others may require several fixed values. So, the PMDs will configur= e it > based on their HW constraints. This results in difference between the use= r > configuration and the actual configuration and this value affects the mem= ory > usage and performance. > I think there's a need for a way to expose that information. So the user can configure X and the driver will use Y!=3DX? Should the application validate its own configurations after setting them s= uccessfully? > > > >>> Maybe document that 0 means - no limitation by HW? > >> > >> Yes, there is no need to fill this filed for HW that has no restrictio= ns on it. > >> I'll add it in v4. > >> > >>> Must application read it in order to know if its datapath should > >>> handle > >> multi-segment buffers? > >> > >> I think it's more appropriate to use scattered_rx to determine if > >> multi- segment buffers should be handled. > >> > >>> > >>> Maybe it will be good to force application to configure scatter when > >>> this > >> field is valid and smaller than max_rx_pkt_len\max_lro.. (<=3D room si= ze)... > > > > Can you explain more what is the issue you came to solve? >=20 > This HW information may be useful when there is some problems running a > application. This structure and related APIs can be used to expose it at = run > time. > > OK