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 E18ECA04B6; Mon, 7 Sep 2020 15:02:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 28F1B1C0BE; Mon, 7 Sep 2020 15:02:25 +0200 (CEST) Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) by dpdk.org (Postfix) with ESMTP id 1A8FA1BF8A for ; Mon, 7 Sep 2020 15:02:22 +0200 (CEST) Received: from hkpgpgate102.nvidia.com (Not Verified[10.18.92.9]) by nat-hk.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Mon, 07 Sep 2020 21:02:21 +0800 Received: from HKMAIL102.nvidia.com ([10.18.16.11]) by hkpgpgate102.nvidia.com (PGP Universal service); Mon, 07 Sep 2020 06:02:21 -0700 X-PGP-Universal: processed; by hkpgpgate102.nvidia.com on Mon, 07 Sep 2020 06:02:21 -0700 Received: from HKMAIL102.nvidia.com (10.18.16.11) by HKMAIL102.nvidia.com (10.18.16.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 7 Sep 2020 13:02:15 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.102) by HKMAIL102.nvidia.com (10.18.16.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 7 Sep 2020 13:02:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cfq9gwaNj+Fd2euU4N227MV7GWru4fCDr7tNR6jr4zgKkdJjvjFAwt1pteU6McJaZUk/xKcCqOKgJTAXZZg2wZexZOSO9huyEgR4S9u91d1IDI5Zu/WeU2MEohJLJ5bMy+nxFaoQb3i0lEXtSYPhC9tvWCtjey7l3O9pIN9Orns5cqWXDtovtYEt4RUP8xRjgcczxqOUj6NV45njx777UyAIEBI+apSEUnqhpRKjPPptRNKS48AvBUtYOLYF//7qc4wKBYwZrCyrg2eVloSf67W1XRSNKBaVwL0GBC3yjFaPsvMQQLIPIBJeU6ZPybcqpjglWUz/rx6ynUpGrjzbhQ== 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=p3/lyJgDRPsGp1QGgdTqHyjJQ9aUFT3YU2k1PNvd3zw=; b=EY92y4NrBgGI4ljzxm6Qr2ZrO+JoWpYYGryXhUOwr6nggn6q33UUGGH96RAUEhaD/Uj1guTFfymPZFlO/vHjSzfbiV1g8MVi/lLwFe96VonQQuHaGrmrkZTAF4EAyARjT2QeP1PeDTJSdk3NeCPOtOtzcNSr7j9DC7dhMFgeTzCqfs36VZmnZPcCADL8a0GszNLv40Yl+URFGEQa0Qsqq33aQUiJQonniYFuzVUXJQiJI76HixDjuxvXJUkDLJ4JsdCWFTIck/hrSiufByNwpiB769AsZ2HHQqkzoWYkMxr5ie+lznLnzNlYr8inYVzVnOYXwznoG5f2Ia/+iHzPBg== 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 MW3PR12MB4491.namprd12.prod.outlook.com (2603:10b6:303:5c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.16; Mon, 7 Sep 2020 13:02:12 +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; Mon, 7 Sep 2020 13:02:12 +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/ykWHNkeaRKxv9sXGxqlT7AawgADRJ4CAADaIUIAAMMIAgAAB59CAAQacAIAFfPZAgAEwlgCAAAaVoIAAQeIAgAAMfmA= Date: Mon, 7 Sep 2020 13:02:12 +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> <66ecf741-ac5b-cf61-66f3-c5df59c1bd49@huawei.com> <5defff09-c8f8-a8f4-b137-0c62ebff2710@huawei.com> In-Reply-To: <5defff09-c8f8-a8f4-b137-0c62ebff2710@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: 4aee7f6b-49b4-4abd-3376-08d8532e3c9e x-ms-traffictypediagnostic: MW3PR12MB4491: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UocIRKEbOX9LtWzSe+N3sj3xUTI6mt6wORChzcfwpQf14mg2Z80fC9qlLgxX6DPHh9Z4icMylcs5u3lpBBP0iK/YgqO/yRimzN+FC/eqD6zy1JRkfFw1spy0IfFSNrr+3zM9whOABQvYCnVDVCQhnrxjR1dXAWDBEPKznqGNkDMUlUyzUUDMV+SD9YwMvApa2HDEWg7APMQzcxx5SCaLCZK5cmeN716L5QTZnr69zxE1i24KW9OFP2VYq2BwS2Wrc2qU7USU47j70j5CZn0ytUARHxrs260dzolHDnyam4UUXNxuduoxtywh2R0Ktd5h2MQAh1QsX/dOOu+gqyg40g== 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)(396003)(366004)(376002)(346002)(136003)(39860400002)(5660300002)(76116006)(66946007)(66446008)(66476007)(66556008)(33656002)(52536014)(64756008)(316002)(71200400001)(2906002)(55016002)(9686003)(110136005)(54906003)(478600001)(86362001)(26005)(186003)(8936002)(8676002)(6506007)(4326008)(53546011)(7696005)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 6dUQ7dMkwwEQov9aQoodkdl/JXivVMIR2UYmmYn3oh/hIf21PKxV4+PHiSTCTUE53pkKY3yZJx8ajFOCGmwSAKzwdtLRAp6K+5DUdSrUTrcFB13hbH4KuaV586Efa0Nos+p7abU2lYSfrP7ufUrbRDQ35upvYZ/LuurzL1V+95Oh9VXFEElPOx8YR+JSe5X+vfWSITijPqt0B++kmrjOYK9v/4Lhp37g6PldR55eLPLdvKcDpQggZUzTzOoNkXIYR19f9xzRyRAZXIMMyL96ve9+GFMIlwz4YRXQHdVI6usKfq78G8/KehBNrUjbCTGUbC6pYE1rXNaZ96jp2kwx8HJKyk3E25oW7WWWe3gn33mxgW1aXwqSXWMzYim1KTPmr6eArRR+Z8GGvaKceM2hKRlpt2EeFL8aA9wquKySrrOXnjFrGllyBeP+amVxOSl347bEmMTTrAcMUonM+PMoYQXz8n8Zf9vQ2OwP5zU/CGasjlaCCrg7ooQFYRqxgYycKczV6JJqjAZ/LleknjSxfDpEhFiIPL9I4fd7jz+b2dLtEkj4zEiaCWobXfRrqo/RrxqwuMVauVWHXBN8+pQ0zHk4yRl0RwgkfvUwNXVVT/EWXcItVyLTKOuPnYt0FSsFXfL8+Li1O4fJzJYRVJUWRQ== 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: 4aee7f6b-49b4-4abd-3376-08d8532e3c9e X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2020 13:02:12.1947 (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: K7mOPNXJBFs8qlcE5ZmJ4lI8ltDX6yXYLB6uTho+EKMRHPEi6bSS3hd3MWJQh78LyRZqRJTPODhI2T6tyyUGzg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4491 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1599483741; bh=p3/lyJgDRPsGp1QGgdTqHyjJQ9aUFT3YU2k1PNvd3zw=; 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=GaWkF1ZgABOunEZRqOokhyKRhesFGJtdLSYafjiYmZGL1O7C9RdzPUkGxMkj0yzTk p9Psij7Zwhda9QsAP+I3FtYedNaabUdZkadKtTi99KexkfQw18ZLlT1exqrQV/CgJX ZttG4CkFusnnCA/xWLNVihNlGAUtLu7vPPlEzv7mViE05i9aIhwUyEFOiG9qg79jcX 2DvLCM3QWG+fM7vAft4FbpXqEubgfToDJ2YCJkCk4xw41IXdmCmj/+1WVGkf17V+Uk fE7Py5AFlNP+uvBcz3hgyQoM4fdsyrxUjAQ4PwCghB7jKmFG0yVT8cLmxBBVJ2vsXt xtix3V/P47iLQ== 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/7 16:28, Matan Azrad wrote: > > > > Hi Chengchang > > > > From: Chengchang Tang: > >> Hi Matan > >> > >> On 2020/9/6 21:45, Matan Azrad wrote: > >>> > >>> Hi Chengchang > >>> > >>> From: Chengchang Tang: > >>>> Hi, Matan > >>>> > >>>> 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(+) > >>>>>>>>>> > > > >>>>> So the user can configure X and the driver will use Y!=3DX? > >>>> > >>>> 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 them > >>>> successfully? > >>>> > >>>> 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 > >>>> applications, they don't care about this value. > >>> > >>> I understand, > >>> 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 > >> alignment supported by the PMD? > >>> Then, application has all the knowledge you want to expose before > >>> the > >> configuration. > >> > >> This may not work because there may be other restrictions besides > >> alignment, which are related to the hardware design. Therefore, it is > >> difficult to describe all constraints in a single field. > >> Moreover, this approach seems to > >> constrain the PMDs and HW to some extent. > > > > Ok, so maybe other ethdev capability API to get the Rx buffer size > adjustment by the PMD? > > Don't you think it is important information to the application in order= to > decide the mempool buffer size \ enabling scatter? >=20 > I guess what you mean is that it's more like a capability, so the applica= tion > should query it through a capability API. Yes. > If i understand correctly, I agree with that. But I think it's okay to us= e this > structure to export queue related information at runtime. It focuses on > querying the current queue configuration. Why do we need it If the capability(suggested above) say it already?=20 > And there seems to be no suitable API for querying this capability. Maybe= we > need to introduce a new API to do this. But I'm not sure if it's really > necessary. =20 For example if the user use room of size X in the RX mempool and the PMD co= nfigures X/2 because of HW limitation: Don't you think it will affect the user configuration of mempool and scatte= r mode? > > In any case, I think you should add documentation in the RX setup API t= hat > the HW buf size may be changed by the PMD. >=20 > There is not a defined rule of how to configure Rx buffer size. That is, = there is > no specific method to configure the Rx buffer size for applications. Howe= ver, > most PMDs configure the Rx buffer size base on the data size of the > mempool. So, if the description is added to the setup API, the method for > configuring the Rx buffer size is determined. I think this issue should i= nvolve > more people in the discussion, maybe we should send a separate patch. The mempool parameter of RX say it exactly, no? > > > > > > . > >