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 0DA1FA034C; Mon, 2 May 2022 23:20:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E01D140C35; Mon, 2 May 2022 23:20:44 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id BD8514069D for ; Mon, 2 May 2022 23:20:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651526442; x=1683062442; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=uY6cttu93omimMTy74pPj+LX8QBV0q62dkMEh+T8y7Q=; b=JZNpbKjvnlA7lkDDCLzo30fAwiu/rfKHb3zNAryqFLZaq/dEVG+4vANT jvI/oAqqk+WDM+RW8bJI6esN+Tjal5EKUrFPBuC+FFH4tp5eTbVlN1DOl pHc+pZYaBkCJ8nvhamZFadb1PK1osPfvCXVm4gnoQMMz3u+DsJhEMm21g n4olIr1sGOJQBVn8/pQBQEAGRBBTzQS3znkh0YB7k/2UziG7tSAJzg/Q4 bYOpUd+KGp/OU6SvMxbhlzXVHITcKQULPieStYGSx85RtPxPmdJKNkAFs k7qjG1fs5f6j2GrNirLsbOKGouM640nzOH6cdxEdbFBy05VyGSfUxiDud Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10335"; a="267207496" X-IronPort-AV: E=Sophos;i="5.91,193,1647327600"; d="scan'208";a="267207496" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 May 2022 14:20:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,193,1647327600"; d="scan'208";a="598804121" Received: from orsmsx606.amr.corp.intel.com ([10.22.229.19]) by orsmga001.jf.intel.com with ESMTP; 02 May 2022 14:20:40 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Mon, 2 May 2022 14:20:40 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Mon, 2 May 2022 14:20:40 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.101) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Mon, 2 May 2022 14:20:39 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VBgJ5A3ui9DC7G9biC/AI+CZc2DSLIQ9peg3ZIZVb+bynM/SwIVatHU6qKFDttBWCbb9uv85r+KYsJNjYhTGOuvpGGZro6ieU9A8P12ZBYFn/JsHfSgXi9lKYakGnXioUymUUybivdnlmD7dSg0Bw2Z588hPaGfa6Ttj2co/4muiVTTcKSp06ICXyNibw3gS4NxvUBiZS74Kbp7nDq9wMhezek0/QcFSl6P6AqLBq6fzbafO482aId69/lE1T0KJLecjtneWl7IkggLRA4osZMEjn+axY56xxGpwQb7Vw8C5jJFputzjlzo7gv9VYHdSy73FIKuSCnNJuoAUD5M+Jw== 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=yNgjQl1zM4DbN5N6vNtmWQwO4LPNUsvGqZv2eJLRK+0=; b=VrUdmD0XyS9tUbPr0OrHKwmLPSrfcvlPflqvqA5sOyNY8t5Yr7NFi/0jjbYn1nx4cL/m96PgmE0XGZPtECrfCq/ATraH0sDwk6eCZVARxFNS3qAIkbwv4+yXq6VJhCduX2+4Q69RvhpW9zDGaDKT1TyC62jIHZFH4yPfzEfJna9HTGSAWzbnH/LhDbmptT/a2+Ob//PuaBHIigAPBsL13gBeONyCUGg2vvaQcug7mSNElnz2lMT6bzqoDb0nZUf633F3n5di96Xmz+/lG2FArUVLECR193aK7rLgc5aIzoP/7h2b3tK0+KQApenFSbzXTWog6saehBEQOwrv3/YmMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from SN6PR11MB3103.namprd11.prod.outlook.com (2603:10b6:805:d7::13) by SN6PR11MB2960.namprd11.prod.outlook.com (2603:10b6:805:d4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5186.23; Mon, 2 May 2022 21:20:37 +0000 Received: from SN6PR11MB3103.namprd11.prod.outlook.com ([fe80::94b8:2101:b64b:c5c7]) by SN6PR11MB3103.namprd11.prod.outlook.com ([fe80::94b8:2101:b64b:c5c7%3]) with mapi id 15.20.5206.012; Mon, 2 May 2022 21:20:37 +0000 From: "McDaniel, Timothy" To: "dev@dpdk.org" CC: "Van Haaren, Harry" , Jerin Jacob , Thomas Monjalon , "Wires, Kent" Subject: rte_bus_probe() does not exit on error Thread-Topic: rte_bus_probe() does not exit on error Thread-Index: AdheaZtQoMN5uFBYRNqhmkEborzgMw== Date: Mon, 2 May 2022 21:20:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.401.20 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5ff80add-2591-4e76-a368-08da2c819a1c x-ms-traffictypediagnostic: SN6PR11MB2960: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: sztpEC9t4zYzj9zUaNEN++La+3ZZtNSvtd/0/RabtRDe2ya8G5jnaVTUE+dVIR+GnsjJhaPzeYZbeVthKofaqrPliTNx4d6OToEuy/1G4OThNQRSEVhKM3VYhEmEOnq7Qyz/HXg2X1BuVkIuqxQACaGQrBmm/qnTslVhHk7ZXeEHTFKKqzSss6jThYzhhIENIGuk2E3jlzZs3htA7LMLJq92CtVd6WSEgEad32cm7oCvja/EjFNVyiSE6pDaC5vbvKZHAkq9PqbCyWmXBcxEq3dsijbSs1Rg4qKwvuICxsf2saPmeALoA6J3H57PHL+vJVhhVPtvQxGA0IYqa9Mb0N68PziUcZdX9tY1ZNwv5vSN5CWOvk7MA/VRBJt2OyopbVa0A5mqm3SaIPm89UACAFFjsHpWq34X8DAyVVgdlzMnKT9pPFMcMQ9ThG9FEyQHB20zfCA+SSRv0jlJOH+KU8oJMwOdy+7H7LWqoDIQmGcwKtkrRXmzIO+cJaXKw0k7nDRqGJ1F6IYY/ZuLe/siJqaVDQIjrm9lW2Ght8bABP+gzNKZ0f8N8k5A+r42gObj/9qzmdfQHykrjCbKb4PTyxrFrSxFg+UERrTw72d1BrQbAB8N4GNC2zG2Yn6UiQppEHrUboNs+M11lX1V6FWIe5mZfp2nS4eOPKKWspqMHd2iQUXiTiJcGwg0tbIlSBmwfP6pCdD/Nj0LXgu7nKcto6PE4UQrcwiTG0xGy2/0/XYh70/u0JjWziZ/0SQJwCaHPkTlKXeOcpz5htRyeX6PoAVF00stlUjX21FKWQhBaad3sNPluB8xjNqYlSf2v0yLnNLHzGt4VSumxI0S9D8rtw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB3103.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(5660300002)(53546011)(82960400001)(71200400001)(6506007)(8676002)(66476007)(66446008)(83380400001)(76116006)(66946007)(66556008)(2906002)(64756008)(122000001)(186003)(33656002)(26005)(86362001)(316002)(45080400002)(55016003)(9686003)(4326008)(8936002)(38100700002)(38070700005)(52536014)(54906003)(7696005)(966005)(6916009)(107886003)(508600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?FYLTB05iBju6VprZD0Qj4vbXQfNo5BcO3a01b1wJQUA8wItMPp5229PiBlv8?= =?us-ascii?Q?FE9U9jZICqLFzqtlg+qYVtZcaLxabXmg0+I+TzJ04LHEDdtprRlqhVbblcVL?= =?us-ascii?Q?uw2JyaUo8fSwW94YUTo0+wKIUg771NKoxV95rdk1lyKE25D549nDkQjrsLiv?= =?us-ascii?Q?Ea6LpuGdOCf5wd42db5b2yyqYJlgE+aTR90RHx9aX2X0nsZLuKzm4d4Wxq4Y?= =?us-ascii?Q?PXnUSAMDxGtn/L8eVPPdtMXKH2lJ7SZR3Y1YhChKO2/V1MlnZbw9tP1i1H/6?= =?us-ascii?Q?cRuShwl4ZUAJjmWdzjfnztcXj8a0jsj0gCPJZehhasUNEMQTB8sqhi1G26R5?= =?us-ascii?Q?VNKtM1jHcV7gsbxVbz7xxuXrZ7XCIJgJlR7tbGWLhSdoW/2AySTsgwqMsNBP?= =?us-ascii?Q?hkxiFjddG549x5fOQAn/Ks4qc7w07wwrFLeMHnDAUmRUarvvpSk1Bo8x8q5U?= =?us-ascii?Q?KiYpespLXOsNbn03a+auvnNEo+kaT5cwv+9sZSecGAzY9H0O5HW3jnSDX2oH?= =?us-ascii?Q?otoJsVNdIu8aU2frg9GIiUSOZFACIkboA8yXWmznSnKS7lvV7mK/p/yTGo8O?= =?us-ascii?Q?+IVXifUZMLEoqt6Ot1Ycvkq/GWUTcQbmoQAbP110K2YyMFBKvNxvqYicr+zZ?= =?us-ascii?Q?eixRKdHCWSeFNOLCiJbPN+2jWMDUtaYxbZJBn1mA2d8VmvSdXIdoJ6hg3GUR?= =?us-ascii?Q?L8o/DObhegLArqEUMlzQZq8RVr9TmxjIL2NNnFKotnoxIEqKiqvYNdUEZBZs?= =?us-ascii?Q?S/SIPJVPDks/6PzWLMiv7FnKihM2ViMn2euUK+U/Pf5+EMDt7g9zuQdm80kK?= =?us-ascii?Q?loJvo+qSdWm8ydynuOQNiORLHoVOW1yYuCqVC9lI+FKxCerNgOVjvyKZckqi?= =?us-ascii?Q?dlrAbIVUonXVgOSYUYpEfm0w557zesetI5ZaPHXXdkR0Lk6mEZd250SbiMiO?= =?us-ascii?Q?/8PJBIrs7suLL+FIfKsudrzrJ3ReS7ulBLUsJvQ2sPU7CG7dTaQ0XLauXW66?= =?us-ascii?Q?Vg+88kWecXQNtLM9YLe+vJ0v546OMzd1POMpWRwDN6WXoKQ6enqfHBGpdcDj?= =?us-ascii?Q?dpdRs7+6b+utIomIhgpHS6p2j5aNqQsoaQy6WKaco+OJMp/cl4Vn5Up2cBet?= =?us-ascii?Q?8T/xhs10jviRq58Gc3nlU8N6gO8rYZeotoJGkekWhAF1vQPveBFuyEYWqOuD?= =?us-ascii?Q?gX8w2iuTWwn9YD5AYCccQJ5WhbSPPGmug/bQC79ed8JpVJIOFB6+Sp6OAOKG?= =?us-ascii?Q?R2ciEnn7v2eC709cGMv3t2qt9Cs3ZKOZzSQygeKkCih40uX6XFPP5jtX3IeB?= =?us-ascii?Q?EbuHX03JytxkuA7wsqixAeQ1261F+6tlmaBJNabuIfYIvJj23pmxMRwkAwqM?= =?us-ascii?Q?7nsOrP4+q2kaRCjjdyIPBM55PtyNDVUxHA+s3TB4wp7z+fp6oKIy2l7A4Qy+?= =?us-ascii?Q?3Hnhl9WpHS+hCnD9G7/6XYGtG6MgT5mL23RaCnyufvbntlaN6zpAxnsUbiCh?= =?us-ascii?Q?KXfI6NhgRVlyCL5i3pyjwZF71BvSYnuPxEZ8YUSyofhhIihbYdrgrZ2TkxKS?= =?us-ascii?Q?F5+lip29Spy39a1uRm6GrekJn7hqcQqP73a+2Eimy2UDpDMGwi6BsmxcWJh7?= =?us-ascii?Q?k+0jM0NE0ZuaUpZNjf6TROLpOEdkT883JDen5dhpobdK+VVFnZqGlAzmc6rL?= =?us-ascii?Q?6p90wQhWRwRvZWcxlDYYwvV0ta6wCIAytIYN/LvaA+SrXTQMYXYIhC8no50w?= =?us-ascii?Q?ymn0fnSMvTS/KgNbExps1H8emtHO6ME=3D?= 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: SN6PR11MB3103.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ff80add-2591-4e76-a368-08da2c819a1c X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2022 21:20:37.3849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: u3hZ2lXC41cyFcTZ6XjwrdNBaGYrEl+IQFbwMuq0uV5NJX+q0uAbPC6xi8MBga4mMDBbloxbtVtn/Tw7/P+HASjzb+sfasgs3znfQpftu+M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2960 X-OriginatorOrg: intel.com X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hello DPDK community, I am following up on a question/comment that I submitted on April 18, for w= hich I have not received any responses. See the original comment below for conte= xt. Are there objections to modifying the behavior of rte_bus_probe() so that i= t propagates any errors detected while processing the command line arguments? It current= ly ignores errors and continues on, always returning success instead of any error that= was returned by the probe function. Thank You, Tim McDaniel > -----Original Message----- > From: dev-request@dpdk.org > Sent: Monday, April 18, 2022 8:20 AM > To: dev@dpdk.org > Subject: dev Digest, Vol 400, Issue 6 >=20 > Send dev mailing list submissions to > dev@dpdk.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://mails.dpdk.org/listinfo/dev > or, via email, send a message with subject or body 'help' to > dev-request@dpdk.org >=20 > You can reach the person managing the list at > dev-owner@dpdk.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dev digest..." >=20 >=20 > Today's Topics: >=20 > 1. [PATCH 1/2] common/mlx5: extend crypto capabilities (Raja Zidane) > 2. RE: [PATCH] kni: update kernel API to receive packets > (Gagandeep Singh) > 3. rte_bus_probe() does not exit on error (McDaniel, Timothy) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Mon, 18 Apr 2022 14:10:04 +0300 > From: Raja Zidane > To: > Cc: > Subject: [PATCH 1/2] common/mlx5: extend crypto capabilities > Message-ID: <20220418111005.2291-2-rzidane@nvidia.com> > Content-Type: text/plain >=20 > Crypto capabilities struct contains info about crypto import method > (wrapped/plaintext DEK) for each of the supported algorithms. >=20 > Query crypto capabilities struct and save import methods. >=20 > Signed-off-by: Raja Zidane > --- > drivers/common/mlx5/mlx5_devx_cmds.c | 13 +++++++++++-- > drivers/common/mlx5/mlx5_devx_cmds.h | 1 + > drivers/common/mlx5/mlx5_prm.h | 29 ++++++++++++++++++++++++++++ > 3 files changed, 41 insertions(+), 2 deletions(-) >=20 > diff --git a/drivers/common/mlx5/mlx5_devx_cmds.c > b/drivers/common/mlx5/mlx5_devx_cmds.c > index d02ac2a678..c6bdbc12bb 100644 > --- a/drivers/common/mlx5/mlx5_devx_cmds.c > +++ b/drivers/common/mlx5/mlx5_devx_cmds.c > @@ -964,12 +964,21 @@ mlx5_devx_cmd_query_hca_attr(void *ctx, > MLX5_GET(cmd_hca_cap, hcattr, > umr_modify_entity_size_disabled); > attr->wait_on_time =3D MLX5_GET(cmd_hca_cap, hcattr, wait_on_time); > attr->crypto =3D MLX5_GET(cmd_hca_cap, hcattr, crypto); > - if (attr->crypto) > - attr->aes_xts =3D MLX5_GET(cmd_hca_cap, hcattr, aes_xts); > attr->ct_offload =3D !!(MLX5_GET64(cmd_hca_cap, hcattr, > general_obj_types) & >=20 > MLX5_GENERAL_OBJ_TYPES_CAP_CONN_TRACK_OFFLOAD); > attr->rq_delay_drop =3D MLX5_GET(cmd_hca_cap, hcattr, rq_delay_drop); > + if (attr->crypto) { > + attr->aes_xts =3D MLX5_GET(cmd_hca_cap, hcattr, aes_xts); > + hcattr =3D mlx5_devx_get_hca_cap(ctx, in, out, &rc, > + MLX5_GET_HCA_CAP_OP_MOD_CRYPTO | > + MLX5_HCA_CAP_OPMOD_GET_CUR); > + if (!hcattr) > + return -1; > + attr->crypto_wrapped_import_method =3D > !!(MLX5_GET(crypto_caps, > + hcattr, > wrapped_import_method) > + & 1 << 2); > + } > if (hca_cap_2_sup) { > hcattr =3D mlx5_devx_get_hca_cap(ctx, in, out, &rc, >=20 > MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE_2 | > diff --git a/drivers/common/mlx5/mlx5_devx_cmds.h > b/drivers/common/mlx5/mlx5_devx_cmds.h > index 1bac18c59d..3747ef9e33 100644 > --- a/drivers/common/mlx5/mlx5_devx_cmds.h > +++ b/drivers/common/mlx5/mlx5_devx_cmds.h > @@ -254,6 +254,7 @@ struct mlx5_hca_attr { > uint32_t umr_indirect_mkey_disabled:1; > uint32_t log_min_stride_wqe_sz:5; > uint32_t esw_mgr_vport_id_valid:1; /* E-Switch Mgr vport ID is valid. *= / > + uint32_t crypto_wrapped_import_method:1; > uint16_t esw_mgr_vport_id; /* E-Switch Mgr vport ID . */ > uint16_t max_wqe_sz_sq; > }; > diff --git a/drivers/common/mlx5/mlx5_prm.h > b/drivers/common/mlx5/mlx5_prm.h > index 44b18225f6..d04c9e32c9 100644 > --- a/drivers/common/mlx5/mlx5_prm.h > +++ b/drivers/common/mlx5/mlx5_prm.h > @@ -1293,6 +1293,7 @@ enum { > MLX5_GET_HCA_CAP_OP_MOD_NIC_FLOW_TABLE =3D 0x7 << 1, > MLX5_SET_HCA_CAP_OP_MOD_ESW =3D 0x9 << 1, > MLX5_GET_HCA_CAP_OP_MOD_VDPA_EMULATION =3D 0x13 << 1, > + MLX5_GET_HCA_CAP_OP_MOD_CRYPTO =3D 0x1A << 1, > MLX5_GET_HCA_CAP_OP_MOD_PARSE_GRAPH_NODE_CAP =3D 0x1C << > 1, > MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE_2 =3D 0x20 << 1, > }; > @@ -3794,6 +3795,34 @@ struct mlx5_ifc_crypto_operational_register_bits { > u8 reserved_at_280[0x180]; > }; >=20 > +struct mlx5_ifc_crypto_caps_bits { > + u8 wrapped_crypto_operational[0x1]; > + u8 wrapped_crypto_going_to_commissioning[0x1]; > + u8 sw_wrapped_dek[0x1]; > + u8 synchronize_dek[0x1]; > + u8 int_kek_manual[0x1]; > + u8 int_kek_auto[0x1]; > + u8 reserved_at_6[0x12]; > + u8 wrapped_import_method[0x8]; > + u8 reserved_at_20[0x3]; > + u8 log_dek_max_alloc[0x5]; > + u8 reserved_at_28[0x3]; > + u8 log_max_num_deks[0x5]; > + u8 reserved_at_30[0x3]; > + u8 log_max_num_import_keks[0x5]; > + u8 reserved_at_38[0x3]; > + u8 log_max_num_creds[0x5]; > + u8 failed_selftests[0x10]; > + u8 num_nv_import_keks[0x8]; > + u8 num_nv_credentials[0x8]; > + u8 reserved_at_60[0x3]; > + u8 log_dek_granularity[0x5]; > + u8 reserved_at_68[0x3]; > + u8 log_max_num_int_kek[0x5]; > + u8 reserved_at_70[0x10]; > + u8 reserved_at_80[0x780]; > +}; > + > struct mlx5_ifc_crypto_commissioning_register_bits { > u8 token[0x1]; /* TODO: add size after PRM update */ > }; > -- > 2.21.0 >=20 >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Mon, 18 Apr 2022 11:33:01 +0000 > From: Gagandeep Singh > To: Stephen Hemminger , Ferruh Yigit > > Cc: Harold Huang , "dev@dpdk.org" > > Subject: RE: [PATCH] kni: update kernel API to receive packets > Message-ID: > urprd04.prod.outlook.com> >=20 > Content-Type: text/plain; charset=3D"us-ascii" >=20 >=20 >=20 > > -----Original Message----- > > From: Stephen Hemminger > > Sent: Friday, April 15, 2022 8:30 PM > > To: Ferruh Yigit > > Cc: Gagandeep Singh ; Harold Huang > > ; dev@dpdk.org > > Subject: Re: [PATCH] kni: update kernel API to receive packets > > > > On Fri, 15 Apr 2022 13:30:33 +0100 > > Ferruh Yigit wrote: > > > > > >> But this change would cause KNI kernel module does not work in the > > > >> old kernel without this patch. I suggested using netif_rx_ni to ke= ep > > compatibility. > > > > > > > > netif_rx() API exists from very older versions of kernel before > > > > v2.6. There will be no compilation issues. Only difference was, > > > > netif_rx_ni() can be used in noninterrupt contexts to improve perfo= rmance. > > > > > > May not be compilation issue, but with old kernels won't the behavior > > > be different when 'netif_rx_ni()' switched to 'netif_rx() > > > > Probably best handled by #ifdef on kernel version but will be a mess fo= r > > backports to distro kernels. > > > > Looks like: > > > > Older -> New > > netif_rx_ni netif_rx > > neitf_rx __netif_rx >=20 > If it is ok for everyone, I can add #ifdef for kernel version >=3D 5.17 t= o use API > netif_rx, to > avoid any functional/performance impact with old kernels. >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Mon, 18 Apr 2022 13:20:10 +0000 > From: "McDaniel, Timothy" > To: "dev@dpdk.org" > Subject: rte_bus_probe() does not exit on error > Message-ID: > amprd11.prod.outlook.com> >=20 > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hello DPDK community, >=20 > We are looking into an issue where we pass an invalid command line argume= nt > to a vdev, and we print out an error message but don't exit. This is an = issue with > all of the command line options that we handle in dlb2_parse_params(). I= n a > nutshell, it looks like when we encounter an error in parsing, the error = code is > propagated to event_dlb2_vdev_probe() (event_dlb2_pci_probe() for PF), wh= ich > is called by EAL during device probe in rte_bus_probe(). The problem is = that > rte_bus_probe() calls the .probe function for each device but doesn't exi= t on > error: >=20 > if (vbus) { > ret =3D vbus->probe(); > if (ret) > RTE_LOG(ERR, EAL, "Bus (%s) probe failed.\n", vbu= s->name); > } > return 0; >=20 > We want to exit if the command line arguments can't be parsed, so we have= a > couple of options: >=20 >=20 > 1. In the DLB PMD, if we get an error while parsing parameters, exit r= ight > away. > 2. Change the behavior of rte_bus_probe() so that it propagates the er= ror, > which causes the program to exit due to EAL error. >=20 > if (vbus) { > ret =3D vbus->probe(); > if (ret) { > RTE_LOG(ERR, EAL, "Bus (%s) probe failed.\n", vbu= s->name); > return ret; > } > } > return 0; >=20 > Any preference, or other ideas? Option 1 is simple and contained in our = code, > but does call rte_exit() from library code. I'm not sure if that's reall= y an issue > because we do want to exit if the DLB-specific options are malformed. Op= tion 2 > is simple and seems like a better option, but requires changes outside of= DLB, so > may be more difficult to upstream? (There may be reasons why the error i= s > ignored for some devices). Let me know what you think. >=20 > Thanks you for your comments, > Tim McDaniel > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > ent.htm> >=20 > End of dev Digest, Vol 400, Issue 6 > ***********************************