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 3294CA04DB; Fri, 16 Oct 2020 19:39:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AC0FFC8F6; Fri, 16 Oct 2020 19:39:09 +0200 (CEST) Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) by dpdk.org (Postfix) with ESMTP id 66FE3C8F4 for ; Fri, 16 Oct 2020 19:39:08 +0200 (CEST) Received: from HKMAIL102.nvidia.com (Not Verified[10.18.92.9]) by nat-hk.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Sat, 17 Oct 2020 00:18:47 +0800 Received: from HKMAIL104.nvidia.com (10.18.16.13) by HKMAIL102.nvidia.com (10.18.16.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 16 Oct 2020 16:18:47 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.173) by HKMAIL104.nvidia.com (10.18.16.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 16 Oct 2020 16:18:47 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CUyM+UlykTBfc9ORi0off/7koxBbUcopXpKpKPFVGWJCYU4cBeUwf885PrmUeIwWVWFFx6+PzE+7x/fbMOPmMrSulc0EeoFwqpYmhBd1wwbAzejGzWYnkD4rowBJU3HpeOTcCLBnGTpxTRf6XS96T/Lps3QoFfMqjrRt1MfMprOkRzVpNaenmXmcxecc/OT25TtpGK2Cy4mcRUDPGJYjFTFnOmI9lIC7rGKRcwYGWzjR53i5Z8Q9qy1eU6VqW0e4Y7aAKdHT82cFZIG2YsdxutMl7LXHKBa4oYPrcjNoWQXCke50GjIkrxHTKAftunsYlq/pMbp2X3uqqM1q3he0PA== 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=+/H63h3DQNM75htrV0oSs2o1a4gweVm+YqVMq9goRM4=; b=OoEr26mOaQb1H00uCBdGEursLscJxVXJ4mc4j6KVV0WQlPczQEpI12cYjfY/GVjVeccPBTqK9wFLhH7lYUWp0cGxUtssnPTNi+VRVihQrphoI6Wldfzg7Jp+iAnpSIpf1On65MhLj0H/4cdrDdb75j0+XtO++rfSn6r9aW9t5j83gkYOqrzeQmuP69phAH8RWXWn94TjMNxk0k9E5Qls0nOZPj24+eIQt0RRf4Fme6BYYqwMxLHvSfpYRQlG/VStWdMho+9RW0G6CmzEwTtABDA/bmnyBaIFmCq9GJy+9d//2wT6875Sm8lgMukiN04l/bdoXcn6i9teSzln36J8+g== 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 MWHPR12MB1360.namprd12.prod.outlook.com (2603:10b6:300:12::7) by MWHPR1201MB0143.namprd12.prod.outlook.com (2603:10b6:301:54::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Fri, 16 Oct 2020 16:18:44 +0000 Received: from MWHPR12MB1360.namprd12.prod.outlook.com ([fe80::191b:81c4:8297:c6ce]) by MWHPR12MB1360.namprd12.prod.outlook.com ([fe80::191b:81c4:8297:c6ce%5]) with mapi id 15.20.3477.020; Fri, 16 Oct 2020 16:18:44 +0000 From: Slava Ovsiienko To: NBU-Contact-Thomas Monjalon CC: "dev@dpdk.org" , "stephen@networkplumber.org" , "ferruh.yigit@intel.com" , "olivier.matz@6wind.com" , "jerinjacobk@gmail.com" , "maxime.coquelin@redhat.com" , "david.marchand@redhat.com" , "arybchenko@solarflare.com" Thread-Topic: [dpdk-dev] [PATCH v11 1/6] ethdev: introduce Rx buffer split Thread-Index: AQHWo8Lo3rn1PW9OGEGzg0E4sgrsKamaVnQAgAARzbA= Date: Fri, 16 Oct 2020 16:18:44 +0000 Message-ID: References: <1602855582-15847-1-git-send-email-viacheslavo@nvidia.com> <1602855582-15847-2-git-send-email-viacheslavo@nvidia.com> <17810755.ypUCan5TCX@thomas> In-Reply-To: <17810755.ypUCan5TCX@thomas> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: monjalon.net; dkim=none (message not signed) header.d=none;monjalon.net; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [95.164.10.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0fadcfd3-104c-4e7e-1a29-08d871ef2750 x-ms-traffictypediagnostic: MWHPR1201MB0143: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rj2gyZrSYP32lZyROMVugRmGg1di1PATwl8m27fcnRNBMlz3b0pmlEiJVdSlgEVszs7ZT/MI2moRxMfvTGV/Lg2i2IGHwNusrI6btiJFo4wmY9Kh97oa2oqDohZfrSSYJguPm82XFhyuNBlF4ZuJA4q+eZsGsC+fgukg9TxyhwsXOR0V/Ll49zvtbZq7CqMe7yRwZe64PBQf2wCeHw7aMRTXpXALvVti2iTeLCfMbn9d5ON0qdyAhVMamHaGOScBBLjkhsmRIQfZUmxVrGDQv+dUoUGUDUkv+sLI3tSgR6Cg7tbxWcThsQV55LhPrTgqumoL5fr1U6Ec9mQ6P3pRqg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR12MB1360.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(346002)(366004)(39860400002)(376002)(9686003)(186003)(26005)(53546011)(6506007)(7696005)(83380400001)(55016002)(33656002)(86362001)(316002)(54906003)(4326008)(66446008)(64756008)(66946007)(76116006)(66476007)(66556008)(8676002)(71200400001)(52536014)(5660300002)(6916009)(478600001)(8936002)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: KZLMeU+2b8LQmLzMdZVOBMGmO1a/fAMtA0UyaimDkbEZT3/VbttclhVgrOrhEUUf7ZfQKpT/KuH7V0eUnrYLmRjO6iplgNmN/fG3HUKIQ6YIqkWI6xWZ6VJ4qge4diQROm6d9ZW416yC/O2qbcDhBZZU4h1GV931Aw9vp35P4DeMed54iSR5uRL2E2Ww8d+zGkf12tm2mRln5Gi9ZSEjbASweD5sD4wq1mbXUUKS9kNJWwqwhHchIeyLJ4+DOqjCk+CGbvb6+6TMzOUR4ZY2thuoAu/ktqJryYJPCUtpbh8KWc8u/CzgG8gh6SKr6jcH71PXgovjXM5KrtJwNUq/8RNXdVF9SXx3PuoZ8fyp52ehtiPfq782KQ1tSJPGHby+krA2JAzfAwTL9DoQitn013uKW+yc4AOhZAq3lNzeMpzzV+9cWQQS5KVx4P5pyCQvIXuIkjijlr5WhPqKir+oKek6osONz74EhwCS8R9zmZpK84MGP5Yj7eDPmXCbPkjSCf/HZ1p8tjglYZnm/0scuT4KKex6wHiSb2b7pVbegXQir7WXUfRoicybu5zjG01zWVqoGBuY7Iy2T2TpwjgKTcw8vEUK017Ra7oVGv3Uw82CZOahswUYff4Chy+Vw9BKThTtOjMzp2iW8YDdFrLG7w== 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: MWHPR12MB1360.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0fadcfd3-104c-4e7e-1a29-08d871ef2750 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 16:18:44.1249 (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: CCthjZZ7u8XqDcRUV7Xto5cHJlhqjUuyQ0g+jFaSl1IggkibvzSZ3J6pkJI4kpfOb/jXDII6Ls29+b3n1CSRQA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1201MB0143 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1602865128; bh=+/H63h3DQNM75htrV0oSs2o1a4gweVm+YqVMq9goRM4=; h=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=fQDaVJPlh5g8f7900wLkkTL5e7RK5u0ENwVQSBMP2O1OiTX6KILw1jzdtAM64SAnA SPht/iy4CS7hR4/897ZfdKJOvcAKVF/S7ELPvaQ8VYP7arppZYnXD76TqJCgre7L3C zFtX8HYUqxjqi6Z8GiLLsuodPOOXk2pQ3/AV1nZGh+kql0U5nUQUcAatdsa+dax4Wh Wfg+elk+zrYV8MkXJRN7n8VWhv1eCTo1HDc5lwoACYhkR6L4PMLmoJSSiHDwav67Xi IWzfa11stLFx16GKE1vqfSFBASAkcYorc4lkifA4TwZ8cxZf5w/+9HH9Lgm+O7RCs5 deL6lCgMw167Q== Subject: Re: [dpdk-dev] [PATCH v11 1/6] ethdev: introduce Rx buffer split 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: Thomas Monjalon > Sent: Friday, October 16, 2020 18:14 > To: Slava Ovsiienko > Cc: dev@dpdk.org; stephen@networkplumber.org; ferruh.yigit@intel.com; > olivier.matz@6wind.com; jerinjacobk@gmail.com; > maxime.coquelin@redhat.com; david.marchand@redhat.com; > arybchenko@solarflare.com > Subject: Re: [dpdk-dev] [PATCH v11 1/6] ethdev: introduce Rx buffer split >=20 > 16/10/2020 15:39, Viacheslav Ovsiienko: > > + if (offset !=3D 0) { > > + if (seg_capa->offset_allowed =3D=3D 0) { > > + RTE_ETHDEV_LOG(ERR, "Rx segmentation > with offset is not supported\n"); > > + return -ENOTSUP; > > + } > > + if (offset & offset_mask) { > > + RTE_ETHDEV_LOG(ERR, "Rx segmentat invalid > offset alignment %u, > > +%u\n", >=20 > small typo: segmentat -> segmentation >=20 > [...] > > /** > > + * A structure used to configure an Rx packet segment to split. > > + * > > + * If RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT flag is set in offloads field, > > + * the PMD will split the received packets into multiple segments > > + * according to the specification in the description array: > > + * >=20 > Minor detail: below bullets should start with a capital letter. >=20 > > + * - the first network buffer will be allocated from the memory pool, > > + * specified in the first array element, the second buffer, from the > > + * pool in the second element, and so on. > > + * > > + * - the offsets from the segment description elements specify > > + * the data offset from the buffer beginning except the first mbuf. > > + * For this one the offset is added with RTE_PKTMBUF_HEADROOM. >=20 > "this one" -> "the first segment, " >=20 > > + * > > + * - the lengths in the elements define the maximal data amount > > + * being received to each segment. The receiving starts with filling > > + * up the first mbuf data buffer up to specified length. If the > > + * there are data remaining (packet is longer than buffer in the fir= st > > + * mbuf) the following data will be pushed to the next segment > > + * up to its own length, and so on. > > + * > > + * - If the length in the segment description element is zero > > + * the actual buffer size will be deduced from the appropriate > > + * memory pool properties. > > + * > > + * - if there is not enough elements to describe the buffer for entire > > + * packet of maximal length the following parameters will be used > > + * for the all remaining segments: > > + * - pool from the last valid element > > + * - the buffer size from this pool > > + * - zero offset > > + */ >=20 > I think the description is precise enough, thanks. >=20 > > +__rte_experimental > > +struct rte_eth_rxseg_split { > > + struct rte_mempool *mp; /**< Memory pool to allocate segment > from. */ > > + uint16_t length; /**< Segment data length, configures split point. */ > > + uint16_t offset; /**< Data offset from beginning of mbuf data buffer. > */ > > + uint32_t reserved; /**< Reserved field. */ }; > > + > > +/** > > + * A common structure used to describe Rx packet segment properties. > > + */ > > +__rte_experimental > > +union rte_eth_rxseg { > > + /* The settings for buffer split offload. */ > > + struct rte_eth_rxseg_split split; > > + /* The other features settings should be added here. */ }; >=20 > OK for having an union. >=20 > > + > > +/** > > * A structure used to configure an RX ring of an Ethernet port. > > */ > > struct rte_eth_rxconf { > > @@ -977,12 +1028,22 @@ struct rte_eth_rxconf { > > uint16_t rx_free_thresh; /**< Drives the freeing of RX descriptors. *= / > > uint8_t rx_drop_en; /**< Drop packets if no descriptors are available= . > */ > > uint8_t rx_deferred_start; /**< Do not start queue with > > rte_eth_dev_start(). */ > > + uint16_t rx_nseg; /**< Number of descriptions in rx_seg array. */ > > /** > > * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. > > * Only offloads set on rx_queue_offload_capa or rx_offload_capa > > * fields on rte_eth_dev_info structure are allowed to be set. > > */ > > uint64_t offloads; > > + /** > > + * Points to the array of segment descriptions. Each array element > > + * describes the properties for each segment in the receiving > > + * buffer according to feature descripting structure. >=20 > Alternative (shorter) wording: > Points to the array of segment descriptions for an entire packet. > Array elements are properties for consecutive Rx segments. >=20 > > + * > > + * The supported capabilities of receiving segmentation is reported > > + * in rte_eth_dev_info ->rx_seg_capa field. >=20 > Rx segmentation capabilities are reported in rte_eth_dev_info.rx_seg_capa= . >=20 > > + */ > > + union rte_eth_rxseg *rx_seg; >=20 > [...] > > + * The configuration structure also contains the pointer to the arra= y > > + * of the receiving buffer segment descriptions, see rx_seg and rx_n= seg > > + * fields, this extended configuration might be used by split offloa= ds like > > + * RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT. If mp_pool is not NULL, > > + * the extended configuration fields must be set to NULL and zero. > > * @param mb_pool > > * The pointer to the memory pool from which to allocate *rte_mbuf* > network > > - * memory buffers to populate each descriptor of the receive ring. > > + * memory buffers to populate each descriptor of the receive ring. T= here > are > > + * two options to provide Rx buffer configuration: > > + * - single pool: > > + * mb_pool is not NULL, rx_conf.rx_seg is NULL, rx_conf.rx_nseg is= 0. > > + * - multiple segments description: > > + * mb_pool is NULL, rx_conf.rx_seg is not NULL, rx_conf.rx_nseg is= not 0. > > + * Taken only if flag RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT is set in > offloads. >=20 > As said previously, I feel rx_conf.rx_seg does not need to be part of the > requirements, as long as rx_conf.rx_nseg is defined. >=20 > All my comments are optional, this version is already very good. > Acked-by: Thomas Monjalon All comments are adopted (in coming v12), thank you. With best regards, Slava