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 D3B6DA04BE; Sun, 6 Sep 2020 15:46:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F25DF2BAB; Sun, 6 Sep 2020 15:46:00 +0200 (CEST) Received: from hqnvemgate25.nvidia.com (hqnvemgate25.nvidia.com [216.228.121.64]) by dpdk.org (Postfix) with ESMTP id EBBAC1DB8 for ; Sun, 6 Sep 2020 15:45:58 +0200 (CEST) Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate25.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Sun, 06 Sep 2020 06:45:09 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Sun, 06 Sep 2020 06:45:58 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Sun, 06 Sep 2020 06:45:58 -0700 Received: from HQMAIL107.nvidia.com (172.20.187.13) by HQMAIL105.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 6 Sep 2020 13:45:50 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.177) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 6 Sep 2020 13:45:50 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nj1uDnXA37gsHsrn25U5J0sG+/E9V12rTFgeWErx04n5e//NAZ4uv7JmuKhxZQUeAtcf3XFxPcRRZjYbL0Hw3hM6tbou6e0DP2nIdKxoEo8yPBH73VjwNEJDmzSJ1IYpD9EhBI9mIxQubNougR7QsNKleSyhioKNW6sZexxq4ScpRc2kANMHTJZW1DUX7eI6sjYJY4n8JkamjFLDRQK/bsF4mwa7cg2F/cYwqFDbsddxhLEAuj0VKTxXoCMQRxPTjgfRV5aeefFCblXxdzsB7ZabLg2y963izXx2QWKPQ6cCCKImGmMeouwZCyhPnZifcvrs5UNyueEJawoQICgZtg== 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=q2DE2UI7qIYe0KLaAzO/G1NwtQ20ro7f/uoqCw34OtQ=; b=k2W0JUNgqctvdtvs/EQ4lHzW2MF5PkuRqj4B9vz2Y9kzEnKlUhl52A9YOBsri+6WWgrHuNbGqzOt3SpMIksCe15DrNDq7Q3Rzjour4FAo9ZZCGJsfFLKRs2hmPDm8k/K0OD34smYaFjoW1TWIJFpbPjHvZC6e14Af04PefhQ6uj+JzKifwOg0baYWAHidtXD2+tU8n/g5UG8dMcVriq/kXGxX5FKCcX0IBoYD1eQbbPRby2gTtc9yxdzdWTrccHvC3eUlcXPmJkmkmBMExm4VNUCI8q1l/SyoBpDL+hvVx6YWmb6Vs0lTp5ysBOyFyI6w/WWdc9B7i/3QxKhILPo2w== 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 MWHPR12MB1485.namprd12.prod.outlook.com (2603:10b6:301:4::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.15; Sun, 6 Sep 2020 13:45:49 +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.3348.019; Sun, 6 Sep 2020 13:45:48 +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/ykWHNkeaRKxv9sXGxqlT7AawgADRJ4CAADaIUIAAMMIAgAAB59CAAQacAIAFfPZA Date: Sun, 6 Sep 2020 13:45:48 +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: 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: 46d017e4-d340-4b12-4ca2-08d8526b29cf x-ms-traffictypediagnostic: MWHPR12MB1485: 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: 45gwVg80KP7TgZuFkPxhVgR7LLDlPJnIz7aE0x6dO+eKWZv3eb6RnhmEOhB5tS2FWs5SLo791UfyuwKsokO/ddUjqIe0oCd5Ve7SDgwPreAcHaLDjzHBumFoj637Bvob6gYtL3NOH5FPz7Fu8HkadjQIxjA+NomDRGRveIdfY8Pgbo3r/O5isoNa4IpDpxzUkPO9Js1xJvc3mzeyVEpk/EHursbuPU1S/dhIMAaNRTqNWpNChKbSHoenJOb2sF0vqXpqU+mlCUYQ9iWLjpSmTLCG/f8jkF4JH9LYN7Vh3w7ty9yOjMIVSGZ1MXhvcXp/b9W29sI3TeZ8V9Y5IGAuGw== 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)(376002)(366004)(136003)(39860400002)(346002)(396003)(53546011)(6506007)(71200400001)(7696005)(86362001)(8936002)(33656002)(66446008)(66476007)(66556008)(64756008)(76116006)(8676002)(2906002)(478600001)(66946007)(52536014)(26005)(5660300002)(186003)(55016002)(4326008)(9686003)(83380400001)(54906003)(316002)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ZXiUNfK2yKIF1EAutanlSddP2/jFwxyvSTH348xKyKomUFBxPel2ahdUYYLN41otGHoQrDCDqv8F4f6jK299J/cEUNV37RY6JL+2D9IIJFH1rPVPRx98/QPK/z2ktww8iIbPXC41sG72P2lbuJg4UBFWqkn1+Ph6rbdBo00mKNVpZLWSbHUlyx9xZL1eckBcoxoK0S1PcAFiiPP4br2XFN6gMlBkhPXQBN2r8YoT5XCKt5PJPa5f5qrg15YxSMexuA4yM35a90H6hb426SOs8mNBcppKGhnM7mHdyCA7Lj0iP7rqpYvEfqzEO77vrgcWl+0rXYY+WX/EjH3WbGaGltc+0zgoNMfm6JhTX01PP73GXU6qA7LkDb9so9ulOI7DgAOPc0NCA9h2kSh+Us5uRwh5Dohid/YyjIJoSA8b6xCyvToOZneUpzrcXL9F/zFj+TvzqgCYlrKMfXKGYv9meAGUJ9JVo7omoAcHOcSKPtP2rOGvDrFDL1Y7YfO6fHcYUJSf+LVvViJfSLfghyNyENkPtmbQMv7w19GFoGHJgcEZa3tzDgXIh8iGvA1GgITKgiphC52aE3opyfvqAe+jVZgUMhVk3ckQPZHwzwXyUZxR9L9sBs8zLKkXVvCMtPAbHWZiWMamQUJKLqu/F/cO9w== 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: 46d017e4-d340-4b12-4ca2-08d8526b29cf X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2020 13:45:48.7246 (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: u1TOkTdyiBgibidHy4S2Ofd2I7GzHe7H1TG6q1BdNBwNOj6Jom4f5yZ4eyV08+TUrla/u8EfZ5x6Ad8+IL5HWQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR12MB1485 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1599399909; bh=q2DE2UI7qIYe0KLaAzO/G1NwtQ20ro7f/uoqCw34OtQ=; 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=kfaAQ4Jb1I/AZpY5LUeJROhSkXZfVMLKjJ/xMR/VG/QPn4cA+jrf3COq8FCvQ6RXe ID2DKFeNIz1orWtmuqnn/0tJ7EHC+wFDJtE8ZCR8BUsdPoTe23Kp0pvmy/YNJX6ZD8 cHYpvL8jlDemoeuuvIE5EhKXbie2NQjzy8wHmWUb/jI72jMltbdoX5qeA/j/1gwWEf oihitzOTvogH6SdBD7N9d31/uVn0WzcLPanFQ4Yzd8uyIerdykTNKSbZTQWE9mX8FU yC4ijDwN7v14Jjq9dKpbm1WWUbLtRVOmsl/9gD/h48eP54J3yAZWhSSqefXRjUem7z YuarVm1rnZIGA== 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 18:30, Matan Azrad wrote: > > Hi Chengchang > > > > From: Chengchang Tang > >> Hi, Matan > >> > >> 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 supp= orted. > */ > >>>>>> 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.... > >> > >> 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). > >> > >> I prefer to consider the structure rte_eth_dev_info as the capabilitie= s. > > > > 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 special > >> in this one? > >> > >> 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 and rx_drop_en in rte_eth_rxconf, some PMDs > >> will adjust it in some cases based on their HW constraints. > > > > Ok, this struct(struct rte_eth_rxq_info) is new for me. > > Thanks for the explanation. > > > >> 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 > >> configure it based on their HW constraints. This results in > >> difference between the user configuration and the actual > >> configuration and this value affects the memory 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? >=20 > Yes, it depends on the HW. In the queue setup API, it just checks whether > the input is greater than the required minimum value. But HW usually has > requirements for alignment and so on. > So when X does not meet these requirements, PMDs will calculate a new > value Y that meets these requirements to configure the hardware (Y <=3D X= , to > ensure no memory overflow occurs). > > Should the application validate its own configurations after setting th= em > successfully? >=20 > It depends on their own needs. The application should not be forced to > verify it to avoid affecting the ease of use of PMDs. For some applicatio= ns, > they don't care about this value. I understand,=20 It looks me like a bad ping-pong between app and PMD (for all the fields in= the struct), And we should avoid adding fields to this structure if we can. What's about adding field in rte_eth_dev_info to expose the rx buffer align= ment supported by the PMD? Then, application has all the knowledge you want to expose before the confi= guration. > > > >>> > >>>>> Maybe document that 0 means - no limitation by HW? > >>>> > >>>> Yes, there is no need to fill this filed for HW that has no restrict= ions 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 > size)... > >>> > >>> Can you explain more what is the issue you came to solve? > >> > >> 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 > > > > . > >