From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 37995A0551 for ; Tue, 21 Jun 2022 07:19:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 29E1241132; Tue, 21 Jun 2022 07:19:10 +0200 (CEST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2069.outbound.protection.outlook.com [40.107.92.69]) by mails.dpdk.org (Postfix) with ESMTP id 1510A40151; Tue, 21 Jun 2022 07:19:08 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nl+zyQUaDLYwR12bHHuhlcIJSEpCi73Y4jlSs0hUAdD+/DBgbxkr1/lsxh8v5/MuwMpfeB2rk4shVshB/qQaJ30nCdkKDn8Y6kCibeN9cABRwOBGZcSNYxz46PD8Iw6NC3jibvWnfzWO0tg2UnqS1rAXJ0e+u5u1VyGFO5/U7JHmKCnXGOZXc+O+a2mvUuNRihb9p4SuVTNeGl9tkWBqVmqQ0ZIrHSO+s2bbOnrBtwDwH9ZHLYTdWTZaTFLSWKS6AQHFFG8mGgLs8bbFm/38SHk9ksOBd5wvgKg0r8WL313TnZaxaFLENImZ8ABgAZcI1GXDuCZaBs6ghcMl1rWlwg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=a9Ei1cPf/vw70q7BCipEZLMiyCnMotYv3pUswGLs9bw=; b=SDG2krC+aTGdXERL3wnuJy1peNh8ZYz7wMiXmoYvkMZsdWhwtWnioehArfZUUNC3iewieBmSJ/TVJERXIkRqBPu4fcicVkLUZS7wFcAlmliYZk0MmrihCRgbKzFeVP1aXs2thvFqNNPOJ5Ba/tvTPlRcTabjzDNaFYv5PfkZwMt/SqGhH35mrBDV96gYZpveWO3WjmvJItjAD1be603jqDZ4rnstcEO1vxk1M+aKqHKlxDUzFLrfMwy22tu7OUdNoszt4pn13WuaLy0llcuxHrJSggGoPGi4ER8aCSPB6q7wTs/tZO8Jyz0nw2XgqN83iPHDTH7FiTlf/P7uZDKcnw== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a9Ei1cPf/vw70q7BCipEZLMiyCnMotYv3pUswGLs9bw=; b=oihgX7R/wGoYqVNhGVPnmKesXl7UPrbFraohUzzZDj+IjoZm5MoUXCLfrcHj2nkehc6gxJck4y5WV9FMS03hfaShzVEngY0mpkD0Bouh/AkBpUYnAIqDEp6hy+01e4sWyRynyvmr6h+1n7HS2AeFBAvIZJtpQmYrUo6AlCj/AUkYVCfilR5CitbbbfiA1hdYKmNrrTzSB5tR/3l3Q2lhGBIDytyxMyjsnDlyzNnD4/pMeW+Y87JHqCJ1yjYiJiA5C//GLog8otCfj6L5bg6llPv4OI4ME+vBDfkH7pM59ZuwyRwYnRFp1tvKcl6leLLh/3/9aVFaXByb5FC0DvLkxg== Received: from DM6PR12MB3753.namprd12.prod.outlook.com (2603:10b6:5:1c7::18) by DM6PR12MB4252.namprd12.prod.outlook.com (2603:10b6:5:211::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.14; Tue, 21 Jun 2022 05:19:06 +0000 Received: from DM6PR12MB3753.namprd12.prod.outlook.com ([fe80::8cc6:67d3:8b2e:ff64]) by DM6PR12MB3753.namprd12.prod.outlook.com ([fe80::8cc6:67d3:8b2e:ff64%6]) with mapi id 15.20.5353.020; Tue, 21 Jun 2022 05:19:06 +0000 From: Slava Ovsiienko To: Xing Zhang , Matan Azrad CC: "dev@dpdk.org" , "stable@dpdk.org" Subject: RE: [PATCH] net/mlx5: add 128B padding of Rx completion entry Thread-Topic: [PATCH] net/mlx5: add 128B padding of Rx completion entry Thread-Index: AQHYb1v0Hv7sS86oSkOpDp6/9uNCya1ZdS4w Date: Tue, 21 Jun 2022 05:19:06 +0000 Message-ID: References: <1653389258-12698-1-git-send-email-zhangxing_neurs@163.com> In-Reply-To: <1653389258-12698-1-git-send-email-zhangxing_neurs@163.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 987fc847-0460-4c44-1afa-08da5345903f x-ms-traffictypediagnostic: DM6PR12MB4252:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: H644DfXNEaeFkuL5RaRY7MGueCx/XltobStDbIp+jqDlHv8Kos7KY+5Pw16oNkuTjy0g1cEigZ2d5XW8stqVZ7Wa5Ak6HotXIlZynQQNXKZcrZ0HC2EUomjp5p5SlzSPIqL9bT9mmB4Gf1KjK+bQ37tj/wsx+aE/Qax3E16kLgZmgJ6t70k5bNq9uKtOXJOpLZSjFZMoIewkoKGiFEMmXxYZP/1s8G6lL70fQ8j/fQt9epMv6ZjmyOftpGj6bvAz0MXqzVVf7ZboofqZiMdwtP7euOxY4xl5HCRMYOZcUrGhJi/ngr6yPfCGCmBHCEb/9eSyuwGg/2gL5b334iKaOY2cS31kwv6DknjB3EsBwpQN/8sKdU/3kxfIMilqMqPoabk03UI5RXB6dilOC90T9IXHb5WI/gDDXgWCOA15riC0WoQ+gwQQbKfjPkUGMmgt4KEPyTXHjo2aMTYp7rrFxXHdm2weyA2z1j4iUbDYZX8pESLXULpT+8FUrNCLAE2Js1PHV7FtFZw+6m8zWM87xHh3R2V/KKRlMFtYY1mrEtJ1NqeXauZf47icCWuDVZdaA6wU7ND90gwvnWgfE57jK0ywsqdF9Xp6FoAam5XI+QH2Vu0afA3iQM/vSkUSmx538dMrXzA/ibE/9VJIbL1rVdl1DpNEeA2f7CjvtaU0KhivkvpZdLKClrzjhUtU+zerowQgmTylUtxtQ65LC6GPJOVviBvFOjPN5cSRmAQHrqA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR12MB3753.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(376002)(396003)(366004)(136003)(39860400002)(346002)(38100700002)(4326008)(8936002)(52536014)(122000001)(5660300002)(2906002)(38070700005)(83380400001)(316002)(6636002)(33656002)(66476007)(66556008)(86362001)(66446008)(8676002)(64756008)(66946007)(76116006)(55016003)(71200400001)(6506007)(7696005)(110136005)(186003)(26005)(54906003)(9686003)(478600001)(41300700001)(53546011)(309714004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?1oYvmbeuCmeU0cejDHOVFyvsjrNsXFvRkiIj1FEDkcTuZxaRqRB5srDtC05z?= =?us-ascii?Q?ErNNhQJSZnHYPAtodFnXsh/y5ioHTLfqU98n2UFRtTj39cr3hPOJrQdyNzBa?= =?us-ascii?Q?fv0tAn1kzib+5fRZAdsvXzmxCCMqX2wMEo0dy8WD9GrkPa6ndL7ugSI//9BQ?= =?us-ascii?Q?COqCaNjNwoRzjQCeEnqNYkjL8xYxgChP0sK83xDhU8YIxoLr1ZdDjHTYBdy+?= =?us-ascii?Q?J8k1EHMry1dkpQ+TczY5LdsvWNNrSl8ZJT1KC2F0Tg1llnck+hYRpEdf9+UI?= =?us-ascii?Q?9W5F3kTI5zbitxDlhzmPPZwCooa+QnZ2KiApnXiN7EzwcOClvqvUiH2+zG/V?= =?us-ascii?Q?WVm9nr0qftAONARg3IPdNBuT6OrqAUkPMSjqXYbAaR6B1TFid+hHKcBQWckG?= =?us-ascii?Q?P3GYENSS0QAuDPknFZ+ez0LIH0UjG/M4AwKdPUs1PXfsJOLFYAnCMvTkwoMu?= =?us-ascii?Q?6llA2oIaaiozh1Mz/xcq2guXCaNPmrztwtP7+vA5La2n0Uk0TVy6meBdVmMA?= =?us-ascii?Q?86U91tCRG9oBnbdILKPOuO7tKp0kBosr/WA2jj6dvNhS3V3geCj+ENPSQc4f?= =?us-ascii?Q?TbKuRalaq1ezyikkgkse09pHzJJC7ySXA0hvuYlUfJZn0E76ifGVykMJR5Z4?= =?us-ascii?Q?PwS/aMPZvdn21zUcJlRbO1yYWb6qPEyBr1qgMhHX8NK+C0e4iqI5x+RI+8kx?= =?us-ascii?Q?V0b4ZcDXn7HB4tmdlgl33cYDsdVykiltj5u5hZllogCcQSe3NZKbaGjhms2S?= =?us-ascii?Q?4OMrRjk2Ec28ZYYY2Fwr1IEB6Ijs/YWR2xX2qDTLIl4kbfgcQUtzNW/4F3Ih?= =?us-ascii?Q?3nIdjFvIx6ktnMHPjQiJFy9P6IboGzNKXpS21uQPEDN8z55yLxDWBPK+Zkrd?= =?us-ascii?Q?GNYfrP/HInh88pGG/SApNP4T/+HaXc4KZT65Z/iU+F9M7TpnO0nhrZ2yodtb?= =?us-ascii?Q?jAo1Oo50GFRaUzmY1wgJXkuPo+4WHu2WlrKzDpg6WNCl07sw8Hwf9j+JocZE?= =?us-ascii?Q?qIC/rwZYyl946Kf6cNYTHHowYEOC9fAEredb7vkytsArz1LHdbS+XRQEFOcX?= =?us-ascii?Q?VATLlXirMGNU2mzWXBkcbWwUhem79CraYlfr+ptEQexEOykrhe8s/3AcVAal?= =?us-ascii?Q?TKzRpWKNiZ4EjsUV/J/+5J0IQoSq2ymFuAY8D3A8oyjqyjXpC+AWGxbKAXNH?= =?us-ascii?Q?2e+bOYNnh67LvTFfEVDd18OUAUPypOUbxlnsp93zjTXEQIex1gfrvyEwEcwr?= =?us-ascii?Q?2MlDP7XtExoL1trXo96feMBOPtq586n4POtBgHFWtTBRNKmwLKT4zBp1/KwJ?= =?us-ascii?Q?JaK37qwoFhIR/aruLHmo4mdIqK4Wscj3Q7K1O+XEyrsXX35z2irqHt/VkDOf?= =?us-ascii?Q?gnyr9O+uu+tbUCbXc0e1mp2qkQOS6v0OxO4fwJ6O5SvfIR5VBbrtKVE9gxP2?= =?us-ascii?Q?4Ezem/xaq9BJUyJoRg537+6qFYnhU58p4pCnwkQXvcEen4IlMjkcvomusVvf?= =?us-ascii?Q?uHYHlnYZ8niU3lzThiItxBb9tS+lRHmqhbTZhrGhDsEC5Jnkge70DtGe+uF9?= =?us-ascii?Q?6Oi1JYy9RsDn7i5W8LPy5hAm631DHb1sufeB+ybilVk3t3hLH+zxiNqLZBA+?= =?us-ascii?Q?oOtOYyPUdB1mLL/HjkN1JS5yhPymrevSA00q7j4MijHeg0sGq5C76cYNCy5f?= =?us-ascii?Q?aQJX4pd400BqnuA9laUVkc4rWZ7rZoT3oCKrd109953f3D0JcgWHz4fMZXR5?= =?us-ascii?Q?GwNFF34jFQ=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3753.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 987fc847-0460-4c44-1afa-08da5345903f X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2022 05:19:06.3781 (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: nVWYG9ZDW2ANvWfLL8EnGEyzSV1+TAuS+HELn5U9XRY66sYf+2KPIPVyIIQ80/5Y25dZxsoI2X/Z5hTbsGKEBQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4252 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Hi, Xing Thank you for the patch, I have some questions about. As far as I can understand we have three flags: 1. HAVE_IBV_MLX5_MOD_CQE_128B_PAD,rdma-core library supports CQE size manag= ement 2. dv_attr.flags (flag MLX5DV_CONTEXT_FLAGS_CQE_128B_PAD), reports device = supports CQE size management 3. RTE_CACHE_LINE_SIZE =3D=3D 128 compile time static option, tells us it = might make sense to configure 128B CQEs What use cases have we got ? 1. HAVE_IBV_MLX5_MOD_CQE_128B_PAD is not defined, no choice, 64B CQE is onl= y option 2. dv_attr.flags - flag is zero, no choice, 64B CQE is only option=20 3. RTE_CACHE_LINE_SIZE =3D=3D 64, configuring CQE to 128B is meaningless, 6= 4B is only reasonable option So, the meaningful use case for the patch looks like the following: HAVE_IBV_MLX5_MOD_CQE_128B_PAD is defined, device supports CQE size mgt, ca= che line size is 128. Right? AFAIU, the patch covers two issues: 1. Fixes the check of dv_attr flag to see whether device supports CQE size = settings This was missed in the existing PMD code and should be fixed anyway. Also, please see mlx5_devx_cq_create() routine - it should be updated to= check dv_attr flag as well. 2. Introduces the new devarg "rxq_cqe_pad_en". We have overwhelming amount of devargs in mlx5 and to introduce the new = one, we must have the strong motivation. What would the new "rxq_cqe_pad_en" allow us? The= only reasonable option I see - explicitly configure 64B CQE size for arch with 128B cacheline. Does i= t make sense? Have you seen real use case of the forcing CQE size to 64B improved the = performance? > + A nonzero value enables 128B padding of CQE on RX side. The size of > + CQE is aligned with the size of a cacheline of the core. If cacheline > + size is 128B, the CQE size is configured to be 128B even though the > + device writes only 64B data on the cacheline. This is to avoid > + unnecessary cache invalidation by device's two consecutive writes on t= o > one cacheline. Sorry, I do not follow. How does 64Bx2 writing cause the cache line invalid= ation? AFAIK, the HW uses L3 cache to store data from PCIe transaction. Writing of= not complete line might cause extra reads from memory to fill up the gaps in li= ne data. L1/L2 caches should be invalidated anyway, regardless of data size. > + However in some architecture, it is more beneficial to update entire > + cacheline with padding the rest 64B rather than striding because > + read-modify-write could drop performance a lot. On the other hand, > + writing extra data will consume more PCIe bandwidth and could also > + drop the maximum throughput. It is recommended to empirically set > + this parameter. Disabled by default. I would consider "enabled by default" to keep the existing behavior. With best regards, Slava > -----Original Message----- > From: Xing Zhang > Sent: Tuesday, May 24, 2022 13:48 > To: Matan Azrad ; Slava Ovsiienko > > Cc: dev@dpdk.org; zhangxing_neurs@163.com; stable@dpdk.org > Subject: [PATCH] net/mlx5: add 128B padding of Rx completion entry >=20 > From: "Xing Zhang zhangxing_neurs@163.com" >=20 > When using Verbs flow engine("dv_flow_en"=3D0)and compile macro contain > HAVE_IBV_MLX5_MOD_CQE_128B_PAD, vendor cap lag is setted to > MLX5DV_CQ_INIT_ATTR_FLAGS_CQE_PAD.But if the device is not support the > capability, this will cause CQ creation failure.So use padded CQE when sy= stem > cache-line size is 128B and the device has the capability of CQE padding.= The > patch that CQE padding device argument should not be deleted. >=20 > Fixes: 4a7f979af28e ("net/mlx5: remove CQE padding device argument") > Cc: stable@dpdk.org >=20 > Signed-off-by: Xing Zhang > --- > doc/guides/nics/mlx5.rst | 19 ++++++++++++++++++- > drivers/net/mlx5/linux/mlx5_os.c | 5 +++++ > drivers/net/mlx5/linux/mlx5_verbs.c | 2 +- > drivers/net/mlx5/mlx5.c | 13 ++++++++++++- > drivers/net/mlx5/mlx5.h | 2 ++ > 5 files changed, 38 insertions(+), 3 deletions(-) >=20 > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index > a0b9284..bd11e5e 100644 > --- a/doc/guides/nics/mlx5.rst > +++ b/doc/guides/nics/mlx5.rst > @@ -14,7 +14,6 @@ ConnectX-6 Lx**, **Mellanox BlueField** and > **Mellanox BlueField-2** families of 10/25/40/50/100/200 Gb/s adapters a= s > well as their virtual functions (VF) in SR-IOV context. >=20 > - > Design > ------ >=20 > @@ -580,6 +579,24 @@ for an additional list of options shared with other > mlx5 drivers. > - POWER9 and ARMv8 with ConnectX-4 Lx, ConnectX-5, ConnectX-6, > ConnectX-6 Dx, > ConnectX-6 Lx, BlueField and BlueField-2. >=20 > +- ``rxq_cqe_pad_en`` parameter [int] > + > + A nonzero value enables 128B padding of CQE on RX side. The size of > + CQE is aligned with the size of a cacheline of the core. If cacheline > + size is 128B, the CQE size is configured to be 128B even though the > + device writes only 64B data on the cacheline. This is to avoid > + unnecessary cache invalidation by device's two consecutive writes on t= o > one cacheline. > + However in some architecture, it is more beneficial to update entire > + cacheline with padding the rest 64B rather than striding because > + read-modify-write could drop performance a lot. On the other hand, > + writing extra data will consume more PCIe bandwidth and could also > + drop the maximum throughput. It is recommended to empirically set > + this parameter. Disabled by default. > + > + Supported on: > + > + - CPU having 128B cacheline with ConnectX-5 and BlueField. > + > - ``rxq_pkt_pad_en`` parameter [int] >=20 > A nonzero value enables padding Rx packet to the size of cacheline on = PCI > diff --git a/drivers/net/mlx5/linux/mlx5_os.c > b/drivers/net/mlx5/linux/mlx5_os.c > index a821153..ef26d94 100644 > --- a/drivers/net/mlx5/linux/mlx5_os.c > +++ b/drivers/net/mlx5/linux/mlx5_os.c > @@ -298,6 +298,11 @@ mlx5_os_capabilities_prepare(struct > mlx5_dev_ctx_shared *sh) > DRV_LOG(DEBUG, "Device supports Multi-Packet RQ."); > } > #endif > +#ifdef HAVE_IBV_MLX5_MOD_CQE_128B_PAD > + /* Whether device supports 128B Rx CQE padding. */ > + sh->dev_cap.cqe_pad =3D RTE_CACHE_LINE_SIZE =3D=3D 128 && > + (dv_attr.flags & MLX5DV_CONTEXT_FLAGS_CQE_128B_PAD); > +#endif > #ifdef HAVE_IBV_DEVICE_TUNNEL_SUPPORT > if (dv_attr.comp_mask & > MLX5DV_CONTEXT_MASK_TUNNEL_OFFLOADS) { > sh->dev_cap.tunnel_en =3D dv_attr.tunnel_offloads_caps & diff > --git a/drivers/net/mlx5/linux/mlx5_verbs.c > b/drivers/net/mlx5/linux/mlx5_verbs.c > index b6ba21c..4ced94a 100644 > --- a/drivers/net/mlx5/linux/mlx5_verbs.c > +++ b/drivers/net/mlx5/linux/mlx5_verbs.c > @@ -200,7 +200,7 @@ mlx5_rxq_ibv_cq_create(struct mlx5_rxq_priv *rxq) > priv->dev_data->port_id); > } > #ifdef HAVE_IBV_MLX5_MOD_CQE_128B_PAD > - if (RTE_CACHE_LINE_SIZE =3D=3D 128) { > + if (priv->config.cqe_pad) { > cq_attr.mlx5.comp_mask |=3D > MLX5DV_CQ_INIT_ATTR_MASK_FLAGS; > cq_attr.mlx5.flags |=3D > MLX5DV_CQ_INIT_ATTR_FLAGS_CQE_PAD; > } > diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c index > 72b1e35..51c92b2 100644 > --- a/drivers/net/mlx5/mlx5.c > +++ b/drivers/net/mlx5/mlx5.c > @@ -46,6 +46,9 @@ > /* Device parameter to enable RX completion queue compression. */ #defi= ne > MLX5_RXQ_CQE_COMP_EN "rxq_cqe_comp_en" >=20 > +/* Device parameter to enable RX completion entry padding to 128B. */ > +#define MLX5_RXQ_CQE_PAD_EN "rxq_cqe_pad_en" > + > /* Device parameter to enable padding Rx packet to cacheline size. */ > #define MLX5_RXQ_PKT_PAD_EN "rxq_pkt_pad_en" >=20 > @@ -2176,7 +2179,9 @@ mlx5_port_args_check_handler(const char *key, > const char *val, void *opaque) > } > config->cqe_comp =3D !!tmp; > config->cqe_comp_fmt =3D tmp; > - } else if (strcmp(MLX5_RXQ_PKT_PAD_EN, key) =3D=3D 0) { > + } else if (strcmp(MLX5_RXQ_CQE_PAD_EN, key) =3D=3D 0) { > + config->cqe_pad =3D !!tmp; > + } else if (strcmp(MLX5_RXQ_PKT_PAD_EN, key) =3D=3D 0) { > config->hw_padding =3D !!tmp; > } else if (strcmp(MLX5_RX_MPRQ_EN, key) =3D=3D 0) { > config->mprq.enabled =3D !!tmp; > @@ -2352,6 +2357,12 @@ mlx5_port_args_config(struct mlx5_priv *priv, > struct mlx5_kvargs_ctrl *mkvlist, > } > DRV_LOG(DEBUG, "Rx CQE compression is %ssupported.", > config->cqe_comp ? "" : "not "); > + if (config->cqe_pad && !dev_cap->cqe_pad) { > + DRV_LOG(WARNING, "Rx CQE padding isn't supported."); > + config->cqe_pad =3D 0; > + } else if (config->cqe_pad) { > + DRV_LOG(INFO, "Rx CQE padding is enabled."); > + } > if ((config->std_delay_drop || config->hp_delay_drop) && > !dev_cap->rq_delay_drop_en) { > config->std_delay_drop =3D 0; > diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h index > 23a28f6..fa41b44 100644 > --- a/drivers/net/mlx5/mlx5.h > +++ b/drivers/net/mlx5/mlx5.h > @@ -140,6 +140,7 @@ struct mlx5_dev_cap { > uint32_t txpp_en:1; /* Tx packet pacing is supported. */ > uint32_t mpls_en:1; /* MPLS over GRE/UDP is supported. */ > uint32_t cqe_comp:1; /* CQE compression is supported. */ > + uint32_t cqe_pad:1; /* CQE padding is supported. */ > uint32_t hw_csum:1; /* Checksum offload is supported. */ > uint32_t hw_padding:1; /* End alignment padding is supported. */ > uint32_t dest_tir:1; /* Whether advanced DR API is available. */ @@ - > 264,6 +265,7 @@ struct mlx5_port_config { > unsigned int hw_vlan_insert:1; /* VLAN insertion in WQE is > supported. */ > unsigned int hw_padding:1; /* End alignment padding is supported. > */ > unsigned int cqe_comp:1; /* CQE compression is enabled. */ > + unsigned int cqe_pad:1; /* CQE padding is enabled. */ > unsigned int cqe_comp_fmt:3; /* CQE compression format. */ > unsigned int rx_vec_en:1; /* Rx vector is enabled. */ > unsigned int std_delay_drop:1; /* Enable standard Rxq delay drop. */ > -- > 2.7.4