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 200D4A04B0; Fri, 7 Aug 2020 13:23:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B59C92B87; Fri, 7 Aug 2020 13:23:10 +0200 (CEST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2088.outbound.protection.outlook.com [40.107.20.88]) by dpdk.org (Postfix) with ESMTP id 7588629D6 for ; Fri, 7 Aug 2020 13:23:09 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fFDRxXUhLiJBdPWrDv9YsEsyxIoa7gzwTez2eEvKiIoFV3MepnjSkG6E6X0Hx1FGW0Mijo0p2DK4Rw0din2/8wEKXfGfN9nGkZ1z4sct6HNrlcUDyoWkUzp83A8TskA6SifUSRz6kO40vxiJRO48nZqbjj7g1/b4IudTSxL4zizHJHrc1p1wuTJMXfb6u0hAyx+1fJpXJbA5IU9yAXs/uhRQU22jkN/th5VnYcjXsRKriroD5m0u/oRBGHBCixMIol9X+DZzgtY92Utd/Ca1lrRm+0XGeoyoCnc+N2Dg0s9hrineZse9ZnMjAov1xqYfO+j4fW6Nc8MMg85T7vFsUQ== 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=eKVLlNEd1qcXR78yQMNJHHYh2uY1sPLW8+rV2lfw9So=; b=B2uAxIIx4duBSJuez1THMgGl6aNp3FmVice6Pa+yLMVmFCINPxUd54R9RyQY5KQnsQ3bIw17I7VJiIoFXPnACSXQksp69L4u76+wuA04fF/6Fs/o6P5J66f7QuUDuLlm+PZdOC1Ivk199ESptBJ4kGwEaUptxVFjkuQG4ST6n7c5joDTYSXdtM2WDuIph6Ovl9Mv4g2gb6K5nmd8LXwFLSgwAmqPjrihhzN6iEGHJupsw8SYmchyWFLfuPROuUpLvXsqxu6KfBMf5R8TumDGJv09J7U3p9zf+cOkaRW91Ojn1VhjTPce2ygWDYFV4B5HAphdHY5e2gFnPkc1hL+rpQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eKVLlNEd1qcXR78yQMNJHHYh2uY1sPLW8+rV2lfw9So=; b=ax0KrZTUMkzrXH59NnOy7Qf5B0fyRtQH3a3engUjUGpOORLnTKxFdCIxRYFH82PLirOW9KWi9MUKeMaQQMy7+fO4GgMlgDIJky9V9zOmaImPPc25CISXcorli3X8eFielbAL9490ill0U11TTekQZt4s4sx3WM9h/xwPEp5WBvc= Received: from AM4PR05MB3265.eurprd05.prod.outlook.com (2603:10a6:205:8::26) by AM4PR0501MB2161.eurprd05.prod.outlook.com (2603:10a6:200:51::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.20; Fri, 7 Aug 2020 11:23:04 +0000 Received: from AM4PR05MB3265.eurprd05.prod.outlook.com ([fe80::194e:dc46:7543:50ed]) by AM4PR05MB3265.eurprd05.prod.outlook.com ([fe80::194e:dc46:7543:50ed%2]) with mapi id 15.20.3239.022; Fri, 7 Aug 2020 11:23:04 +0000 From: Slava Ovsiienko To: Stephen Hemminger CC: Ferruh Yigit , Jerin Jacob , dpdk-dev , Matan Azrad , Raslan Darawsheh , Thomas Monjalon , Andrew Rybchenko , Ajit Khaparde , Maxime Coquelin , Olivier Matz , David Marchand Thread-Topic: [PATCH] doc: announce changes to ethdev rxconf structure Thread-Index: AQHWaY004L3In00ZQUyYfiksfQDfi6kmV4VAgAGc6ACAA01KAIAAB7eAgAAJ5/CAABMzAIABH6sg Date: Fri, 7 Aug 2020 11:23:03 +0000 Message-ID: References: <1596452291-25535-1-git-send-email-viacheslavo@mellanox.com> <20200806092559.614ae91f@hermes.lan> <20200806111008.1905c576@hermes.lan> In-Reply-To: <20200806111008.1905c576@hermes.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: networkplumber.org; dkim=none (message not signed) header.d=none;networkplumber.org; dmarc=none action=none header.from=mellanox.com; x-originating-ip: [95.164.10.10] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 429c8f9d-b723-4d74-537f-08d83ac44065 x-ms-traffictypediagnostic: AM4PR0501MB2161: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr,ExtFwd x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Atoa7yP1XmDL6sKuJDYnnV1bhN5+24jYBnlc20Yp7KF3vBnGmweoxcXH/xfK2koIa6eDP4iW9AvUBfrlMobcFJVTOmw4lqY2oDqqSi8fETlxwP7O23j3mr6uocPHIYvIfhYAHluZLMDkgpFFKxLqLo+gXeOyJnkMexE1BFFMFBfOhSGB3yZi1YqcX5TOo65C0N08eN79VYSCU3gmz6qwRsLUXnmWg9FLsJ+C83CNXokiIuNPr+NXF3zRaDLQzFD+ht2B7ET7t2eRCWp/rePKD20dO65EDjdiOfRpZxbk4Mj2gwmk84VLo+O+EVaGIr/Et0+CVqrXLTs2NiwNOneTPA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR05MB3265.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(136003)(396003)(376002)(39860400002)(33656002)(83380400001)(71200400001)(26005)(9686003)(508600001)(186003)(7416002)(2906002)(76116006)(55016002)(66446008)(66556008)(86362001)(66476007)(64756008)(66946007)(6916009)(54906003)(8676002)(7696005)(5660300002)(4326008)(52536014)(53546011)(6506007)(8936002)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: HEbMW5M7kYsf58np0bOVR1t4bhWVdOBuQoxX7nEzgwhj8nmisJ4N5patgbJEo5E0a3AUwlb0kfbEMs6X4Ami7tnSOYZrJPdHqwhctyCKMgODfs9bPufqufivGdg2y7Gqp4AYCqhnVkayNGe6kIJylFiMoisRJTzAUAYevY0xu4MDL5BYFh30EBt5V7kNJISUJS5KQZcUVF+tbopxwt8pg0F7QV+Uy7i3vott/wTduj8Ea2QMLJGX8bX9miIyD1Xpapt1c3U5KrRYW7YUnZNc2AallXIP6UogWo0lMg7NtIJzQEKDQW40WdNPHCDZWUC5Q4cHjuVGQD0n0Ge0OFRdMGOtALhrIGzz/c1a3kPslKI2Fkk70YiPn7JhXEuSOddJAsZG7+vhkpvSzc/NGViH1y3CjR9Ht4xK39ZjojiVmcyd57jX4s/BKRdrq3IjjwuEDX2zxpHv4VRm5r28y0ME8mmfJSMOv4FRvmXFaXOojwyTIfSAcEGGC22PxaEIpqdkqeSMgqwinhIDatk6RQlmBSQDzpThS0+T5n6ZsLeOIPf2VRYAXssMsPFk6WnlpRyHKr7aFXYI2FH2cFKoj11e7UuChh7RsrN1+aDja9xEoPPKRG2CFU0js9HTEMKnS1Oi7yKGBzWIz9faW7bkxFN0Mw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM4PR05MB3265.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 429c8f9d-b723-4d74-537f-08d83ac44065 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2020 11:23:03.9519 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: I+dS4HJOVIz2j8DdnPHef1/ij20Tw+8tbhh1V65Q+AX2gx9IMGqxbb7Y9Zqok8u4ibAOVFxOpbFYCNyJlghn+iC+HD311KmZ5h9ur8BNBWE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0501MB2161 Subject: Re: [dpdk-dev] [PATCH] doc: announce changes to ethdev rxconf 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" > -----Original Message----- > From: Stephen Hemminger > Sent: Thursday, August 6, 2020 21:10 > To: Slava Ovsiienko > Cc: Ferruh Yigit ; Jerin Jacob > ; dpdk-dev ; Matan Azrad > ; Raslan Darawsheh ; > Thomas Monjalon ; Andrew Rybchenko > ; Ajit Khaparde > ; Maxime Coquelin > ; Olivier Matz ; > David Marchand > Subject: Re: [PATCH] doc: announce changes to ethdev rxconf structure >=20 > On Thu, 6 Aug 2020 17:03:31 +0000 > Slava Ovsiienko wrote: >=20 > > > -----Original Message----- > > > From: Stephen Hemminger > > > Sent: Thursday, August 6, 2020 19:26 > > > To: Ferruh Yigit > > > Cc: Jerin Jacob ; Slava Ovsiienko > > > ; dpdk-dev ; Matan Azrad > > > ; Raslan Darawsheh ; > > > Thomas Monjalon ; Andrew Rybchenko > > > ; Ajit Khaparde > > > ; Maxime Coquelin > > > ; Olivier Matz > ; > > > David Marchand > > > Subject: Re: [PATCH] doc: announce changes to ethdev rxconf > > > structure > > > > > > On Thu, 6 Aug 2020 16:58:22 +0100 > > > Ferruh Yigit wrote: > > > > > > > On 8/4/2020 2:32 PM, Jerin Jacob wrote: > > > > > On Mon, Aug 3, 2020 at 6:36 PM Slava Ovsiienko > > > wrote: > > > > >> > > > > >> Hi, Jerin, > > > > >> > > > > >> Thanks for the comment, please, see below. > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Jerin Jacob > > > > >>> Sent: Monday, August 3, 2020 14:57 > > > > >>> To: Slava Ovsiienko > > > > >>> Cc: dpdk-dev ; Matan Azrad > ; > > > > >>> Raslan Darawsheh ; Thomas Monjalon > > > > >>> ; Ferruh Yigit ; > > > > >>> Stephen Hemminger ; Andrew > > > Rybchenko > > > > >>> ; Ajit Khaparde > > > > >>> ; Maxime Coquelin > > > > >>> ; Olivier Matz > > > > >>> ; David Marchand > > > > >>> > > > > >>> Subject: Re: [PATCH] doc: announce changes to ethdev rxconf > > > > >>> structure > > > > >>> > > > > >>> On Mon, Aug 3, 2020 at 4:28 PM Viacheslav Ovsiienko > > > > >>> wrote: > > > > >>>> > > > > >>>> The DPDK datapath in the transmit direction is very flexible. > > > > >>>> The applications can build multisegment packets and manages > > > > >>>> almost all data aspects - the memory pools where segments are > > > > >>>> allocated from, the segment lengths, the memory attributes > > > > >>>> like > > > external, registered, etc. > > > > >>>> > > > > >>>> In the receiving direction, the datapath is much less > > > > >>>> flexible, the applications can only specify the memory pool > > > > >>>> to configure the receiving queue and nothing more. In order > > > > >>>> to extend the receiving datapath capabilities it is proposed > > > > >>>> to add the new fields into rte_eth_rxconf structure: > > > > >>>> > > > > >>>> struct rte_eth_rxconf { > > > > >>>> ... > > > > >>>> uint16_t rx_split_num; /* number of segments to split */ > > > > >>>> uint16_t *rx_split_len; /* array of segment lengthes */ > > > > >>>> struct rte_mempool **mp; /* array of segment memory pools > > > > >>>> */ > > > > >>> > > > > >>> The pool has the packet length it's been configured for. > > > > >>> So I think, rx_split_len can be removed. > > > > >> > > > > >> Yes, it is one of the supposed options - if pointer to array of > > > > >> segment lengths is NULL , the queue_setup() could use the > > > > >> lengths from > > > the pool's properties. > > > > >> But we are talking about packet split, in general, it should > > > > >> not depend on pool properties. What if application provides the > > > > >> single pool and just wants to have the tunnel header in the > > > > >> first dedicated > > > mbuf? > > > > >> > > > > >>> > > > > >>> This feature also available in Marvell HW. So it not specific > > > > >>> to one > > > vendor. > > > > >>> Maybe we could just the use case mention the use case in the > > > > >>> depreciation notice and the tentative change in rte_eth_rxconf > > > > >>> and exact details can be worked out at the time of implementati= on. > > > > >>> > > > > >> So, if I understand correctly, the struct changes in the commit > > > > >> message should be marked as just possible implementation? > > > > > > > > > > Yes. > > > > > > > > > > We may need to have a detailed discussion on the correct > > > > > abstraction for various HW is available with this feature. > > > > > > > > > > On Marvell HW, We can configure TWO pools for given eth Rx queue. > > > > > One pool can be configured as a small packet pool and other one > > > > > as large packet pool. > > > > > And there is a threshold value to decide the pool between small > > > > > and > > > large. > > > > > For example: > > > > > - The small pool is configured 2k > > > > > - The large pool is configured with 10k > > > > > - And if the threshold value is configured as 2k. > > > > > Any packet size <=3D2K will land in small pool and others in a la= rge pool. > > > > > The use case, we are targeting is to save the memory space for > > > > > jumbo > > > frames. > > > > > > > > Out of curiosity, do you provide two different buffer address in > > > > the descriptor and HW automatically uses one based on the size, or > > > > driver uses one of the pools based on the configuration and > > > > possible largest packet size? > > > > > > I am all for allowing more configuration of buffer pool. > > > But don't want that to be exposed as a hardware specific requirement > > > in the API for applications. The worst case would be if your API chan= ges > required: > > > > > > if (strcmp(dev->driver_name, "marvell") =3D=3D 0) { > > > // make another mempool for this driver > > > > > I thought about adding some other segment attributes, vendor specific. > > We could describe the segments with some descriptor structure (size, > > pool) and add flags field to one. The proposals from other vendors are > welcome. > > >=20 > Please no snowflake API's "are driver is special"... >=20 > Think of how it can fit into a general model. > Also, just because your hardware has a special feature does not mean the > DPDK has to support it! Sure. The initial proposal is just about how to extend the Rx buffers descr= iption. Now it is the single pool and the single fixed segment size only. Not very = flexible so far. With best regards, Slava