From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 2ECA6A0C47;
Sat, 18 Sep 2021 07:28:58 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 9844B40041;
Sat, 18 Sep 2021 07:28:57 +0200 (CEST)
Received: from mga12.intel.com (mga12.intel.com [192.55.52.136])
by mails.dpdk.org (Postfix) with ESMTP id F327D4003D
for <dev@dpdk.org>; Sat, 18 Sep 2021 07:28:55 +0200 (CEST)
X-IronPort-AV: E=McAfee;i="6200,9189,10110"; a="202413962"
X-IronPort-AV: E=Sophos;i="5.85,303,1624345200"; d="scan'208";a="202413962"
Received: from orsmga006.jf.intel.com ([10.7.209.51])
by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
17 Sep 2021 22:28:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.85,303,1624345200"; d="scan'208";a="434306205"
Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83])
by orsmga006.jf.intel.com with ESMTP; 17 Sep 2021 22:28:52 -0700
Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by
fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2242.12; Fri, 17 Sep 2021 22:28:52 -0700
Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by
fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2242.12 via Frontend Transport; Fri, 17 Sep 2021 22:28:52 -0700
Received: from NAM04-MW2-obe.outbound.protection.outlook.com (104.47.73.172)
by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.1.2242.12; Fri, 17 Sep 2021 22:28:51 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=CZRHIfGizgeDZYBXaYN1DqarNHJp9MhGNmNnpEiKnl9rJGXu5FReTDV1unX/1dzfsJYAs3njN8mYkmZTM+cn+Vbd6s3Ksx8MIIyKNQmfS3bJ2y2rmMyAza5sqCO7RNdAzRrOHm1QhQuW7pBrXYCm5ygQEcooMNMCjMBgkG50xewAZlEGFGOM5R+43aw/wPZi77dx0pXS/8DNfrgsqUk3ZnBFm/Z2EgG/l5Sqt/0BRqhUG5ekfyl0VLi1E/z8qj+YfR+R50o8YYiMAibJJF43OhUbGitc0P6xWSLJvCCedA66GIOc9sp3v1Dp08lHEF+UbCl6KlyDrtHQ9Jwue0uICg==
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;
bh=hPYYPk28qrvOkOk3hP604CGgGzX3GATZ8NogjnYwgQ4=;
b=JHMHYa7FNyoVQ1ecE21NN5zxSRb4PtflKvzQQBpX+HUbqogADZAsLIlUS/3fOF5X3rk1q9d4taIcjzqFRbE+ND2VnqQKTrKUEdwHOwa7URXeKbTUneQIOX/AXmQfhsLZDYTgBDP3+7iJQpx0twHJingT5WMUJ/CtLQRA660CoAuq4lfDBi3YobkwyflM0fqV9vnMbRauZUSLILw/S0PgXZLTYv262c02GAjyyC3jtPiwvWEAv9CXuQXwdG7v2u2hmGAyhCIcsoItIMkeoIVQDHSf3OgfCJeP3ZeEbcRwJEympjdrDUq3QHS3JLIs1mA2c2Vo8UOa5TqboPyrqUbOXg==
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
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;
s=selector2-intel-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=hPYYPk28qrvOkOk3hP604CGgGzX3GATZ8NogjnYwgQ4=;
b=bMg4UT9seobIBUPC2+GEspjzPFOMfYoy6muTq25Y19VgGRn2fDCpPIiZXYIxOh5HUFVGF2MuUvTMauZ/gKj8+uW7vU7IOfvIU2qLI3ZtiUzhv8yo1V/Z1xGhPyANVO07R7S31RTjncfZBV8g7SNEvzFZN6/MbHzswn3qOWzjl98=
Received: from MW3PR11MB4587.namprd11.prod.outlook.com (2603:10b6:303:58::7)
by MWHPR11MB1694.namprd11.prod.outlook.com (2603:10b6:300:21::23) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.16; Sat, 18 Sep
2021 05:28:48 +0000
Received: from MW3PR11MB4587.namprd11.prod.outlook.com
([fe80::4d0f:beef:ae28:d933]) by MW3PR11MB4587.namprd11.prod.outlook.com
([fe80::4d0f:beef:ae28:d933%5]) with mapi id 15.20.4523.018; Sat, 18 Sep 2021
05:28:47 +0000
From: "Wu, Jingjing" <jingjing.wu@intel.com>
To: "Nicolau, Radu" <radu.nicolau@intel.com>, "Xing, Beilei"
<beilei.xing@intel.com>, "Richardson, Bruce" <bruce.richardson@intel.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>, Ray Kinsella
<mdr@ashroe.eu>
CC: "dev@dpdk.org" <dev@dpdk.org>, "Doherty, Declan"
<declan.doherty@intel.com>, "Sinha, Abhijit" <abhijit.sinha@intel.com>,
"Zhang, Qi Z" <qi.z.zhang@intel.com>
Thread-Topic: [PATCH v2 2/4] net/iavf: add iAVF IPsec inline crypto support
Thread-Index: AQHXqjc6/EHTH3plN0SlCwOXijJ09qupPJvQ
Date: Sat, 18 Sep 2021 05:28:47 +0000
Message-ID: <MW3PR11MB4587DF4A188262B67E681501E3DE9@MW3PR11MB4587.namprd11.prod.outlook.com>
References: <20210909142428.750634-1-radu.nicolau@intel.com>
<20210915133211.1310791-1-radu.nicolau@intel.com>
<20210915133211.1310791-3-radu.nicolau@intel.com>
In-Reply-To: <20210915133211.1310791-3-radu.nicolau@intel.com>
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.200.16
authentication-results: intel.com; dkim=none (message not signed)
header.d=none;intel.com; dmarc=none action=none header.from=intel.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7ce144b7-fcc8-44e4-e089-08d97a6530da
x-ms-traffictypediagnostic: MWHPR11MB1694:
x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MWHPR11MB1694E5B00B51CD525C952452E3DE9@MWHPR11MB1694.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Kl2yLvuYFzCApnOrlR4NiZI9RjTsISVoxw9bd8qZOgjhtT7GEnEwWGsfTFP5XvZXCCZTOV7QwSvA1O/wgqmlu2xdnxbwbh5ofAF7oT3Klcyzovs4M1bAB3n+OH0Gj5WyF/j/BY9qhZ1ZzpBrOhn5W1NiQ89JGVWQqTAmen+9ETR5FDLNDuKxlR7Y/FarBRTwEGLGnzJhfED6ukvUlMeV3tXYSZnlbnpCGF5jQmSMveTCFA/PRGZSmThcn0IKN/CsdmBFjV5JwpuKuE6FB/ILjaLBXlyYS7cZCi7QjwPUXTZefZu94KFaiiSTt5gJwX+BrOFmQ7qiKZKH/qDh5d4FxibRgwBRoUh8dNANfPN/uc0isA8OOmfUfAIbuty4Y60ppUm1XmpPnb0FB/DLfZ+vSdU99S4x7Huz8kbods2SppTCOZGtvU15ZVfGeQfSUAxa376qv6fnpBt9ebf1fzs6/AedRqjYUsIj9YuuIgRtw+A9UpAMGV1sEnawFOjQzeiXNi2pEOO/vWMLpkEUeHT4FMWtYZnwfhI0B5AbeoUwhARkt8nfQo16qgAhFGBY1vOKBgELhp+hufbxzZCwH0ilrKs0zMtnpMjjDLwwjG3YGzxYQLPx1IB0D23b4wvLMDXt+Mz0EInb40FMC1TDDcd/CM4MRRpxeF/Y6zl/EJ1J/AJbcjsjwbXlSlehrJ9RLDIz9LvehWQ8k999Ya+ApKqdbg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:MW3PR11MB4587.namprd11.prod.outlook.com; PTR:; CAT:NONE;
SFS:(4636009)(366004)(8936002)(9686003)(64756008)(55016002)(83380400001)(66446008)(107886003)(66556008)(76116006)(66476007)(66946007)(86362001)(52536014)(316002)(508600001)(71200400001)(6506007)(33656002)(8676002)(38100700002)(26005)(7696005)(110136005)(54906003)(2906002)(4326008)(122000001)(38070700005)(5660300002)(186003);
DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?yqZnKqgJ7D+lhO8/I4RuibP2wIZ6QDY6Y2ynqPFt4d0XOcltWNJu+udcl/d5?=
=?us-ascii?Q?qtY7s6+1qs5KD7PGqZ0t9BPINlDv4pHie8oqOylObbbF2E0+mbvZiKUrT78I?=
=?us-ascii?Q?NdGI5PjKMcnD2KZM2lq+dJqCwsSqJOzm+mDpiQ1g7vAz1/IWCoYN6B9dYLFR?=
=?us-ascii?Q?g3FXuFjT2dDxsuoKPqgkpLLO5n+8mDNKucNkqvpAOVu/jGiJP6hegF7MrQd2?=
=?us-ascii?Q?HnTMKD5ZlGY6BOtkPznJuDuJ+YzqZwJRhWFtmajkEdjHvR98X8zVowF4NdN7?=
=?us-ascii?Q?PUg7N0vpq3asp0mAV/Y7nSREvIlMVLAvz28EenAo2XyL/LWkxU5/FpUOa811?=
=?us-ascii?Q?D39tCSDK2Ul4uCF5oJ9uFRDJxPHLLg0N4W3TkrYlTSyYBWy4SMJRuDwhYA1G?=
=?us-ascii?Q?+c4Fv0Yu2BZKjy7sZV9ab9vlu0lVkOfEULJMmhrbz8Yi9ORYtUaVrzOH7euo?=
=?us-ascii?Q?aBAyMmuOl0BbUVo137qCKGldhHcDsxiSMz4+hdbS1jgycSrHuf1yLayQJ7yr?=
=?us-ascii?Q?9ZXg46feBVgIajcDffYZVFFmFfje4CkXaiO+BTNQbgL7/btMEciDpi6wh4XM?=
=?us-ascii?Q?NxQ13DoCcr3xgPU2ZBTQpJ86HIMQa//1bPJr8W3jfQHco6rZJE1dfIddFVJ/?=
=?us-ascii?Q?nez7PT86rqf5W/9lLGI5Si4N+rifiIylf6viDpk4Z3PwoIFI4grdN+QolLgF?=
=?us-ascii?Q?jzpCG2OpBxqSW6DufPGTNM4riS+L0ypHq6gMZpeigF7CQpaXOrmpoEQ9Noo3?=
=?us-ascii?Q?Ege9mfNCZkeX4erH6pphTOt5QPTg7zxCot7Bw2smAuOJjjl89TAseXI49dM6?=
=?us-ascii?Q?Oak1v51aZzqwK1ZoQeu6ybC190ydFwM0Wpse0uCEnckZmSfxs5BBhlrfgF05?=
=?us-ascii?Q?yg8iC6VugF+JigT4HqjHwMcGhzmg2IK+cD+20MQkwnGFnPpKajcwAAtxjcHo?=
=?us-ascii?Q?peIkJrJDt2zPBHjE2XOZJedTO650JH9wVw39ADNIL0IhUrvFvcvIvQaGHBZw?=
=?us-ascii?Q?PWcDD4AbiUVaHn+rgP+wfeAtVH1QiSvRasKTkMj28oY1HdFIyWpvvut1nOIB?=
=?us-ascii?Q?yI7te+xTgjw3dYS3t0nIfSQi0/SShRWg8OMpP7HfCJ6ZKxGWzzCUN9OB5oh2?=
=?us-ascii?Q?XAgTuqHChXq545/Y/UT/QwhN4OodgNDCJNgNWgsI/c6r69UTTdA84rhCs4YS?=
=?us-ascii?Q?rznhIywatT8RHbD+6+d7Go+wRDMpOX87ykIfIi2Yk70Ogn0NKJuuLoRbUVsl?=
=?us-ascii?Q?9JsJ2alv6XdaOlOoD2BavD1TTBemGHFpIh9ZoK/9pim+t57Wv+SYva4mKPrr?=
=?us-ascii?Q?pkcO3TQnD+6kTmkVDuxGFj76?=
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: MW3PR11MB4587.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ce144b7-fcc8-44e4-e089-08d97a6530da
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2021 05:28:47.7182 (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: 7mLWy7KzhtbmnXiO7qU2GeucSApU3vO99+3Q9LuT2hkwWqA8DSZ+GdzJMvYr6vg4uFOf3WmN706+lFZvlFBXvw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1694
X-OriginatorOrg: intel.com
Subject: Re: [dpdk-dev] [PATCH v2 2/4] net/iavf: add iAVF IPsec inline
crypto support
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
In general, the patch is too big to review. Patch split would help a lot!
[...]
> +static const struct rte_cryptodev_symmetric_capability *
> +get_capability(struct iavf_security_ctx *iavf_sctx,
> + uint32_t algo, uint32_t type)
> +{
> + const struct rte_cryptodev_capabilities *capability;
> + int i =3D 0;
> +
> + capability =3D &iavf_sctx->crypto_capabilities[i];
> +
> + while (capability->op !=3D RTE_CRYPTO_OP_TYPE_UNDEFINED) {
> + if (capability->op =3D=3D RTE_CRYPTO_OP_TYPE_SYMMETRIC &&
> + capability->sym.xform_type =3D=3D type &&
> + capability->sym.cipher.algo =3D=3D algo)
> + return &capability->sym;
> + /** try next capability */
> + capability =3D &iavf_crypto_capabilities[i++];
Better to check i to avoid out of boundary.
[...]
> +
> +static int
> +valid_length(uint32_t len, uint32_t min, uint32_t max, uint32_t incremen=
t)
> +{
> + if (len < min || len > max)
> + return 0;
> +
> + if (increment =3D=3D 0)
> + return 1;
> +
> + if ((len - min) % increment)
> + return 0;
> +
> + return 1;
> +}
Would it be better to use true/false instead of 1/0? And the same to follow=
ing valid functions.
[...]
> +static int
> +iavf_ipsec_crypto_session_validate_conf(struct iavf_security_ctx *iavf_s=
ctx,
> + struct rte_security_session_conf *conf)
> +{
> + /** validate security action/protocol selection */
> + if (conf->action_type !=3D RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO ||
> + conf->protocol !=3D RTE_SECURITY_PROTOCOL_IPSEC) {
> + PMD_DRV_LOG(ERR, "Unsupported action / protocol specified");
> + return -EINVAL;
> + }
> +
> + /** validate IPsec protocol selection */
> + if (conf->ipsec.proto !=3D RTE_SECURITY_IPSEC_SA_PROTO_ESP) {
> + PMD_DRV_LOG(ERR, "Unsupported IPsec protocol specified");
> + return -EINVAL;
> + }
> +
> + /** validate selected options */
> + if (conf->ipsec.options.copy_dscp ||
> + conf->ipsec.options.copy_flabel ||
> + conf->ipsec.options.copy_df ||
> + conf->ipsec.options.dec_ttl ||
> + conf->ipsec.options.ecn ||
> + conf->ipsec.options.stats) {
> + PMD_DRV_LOG(ERR, "Unsupported IPsec option specified");
> + return -EINVAL;
> + }
> +
> + /**
> + * Validate crypto xforms parameters.
> + *
> + * AEAD transforms can be used for either inbound/outbound IPsec SAs,
> + * for non-AEAD crypto transforms we explicitly only support CIPHER/AUT=
H
> + * for outbound and AUTH/CIPHER chained transforms for inbound IPsec.
> + */
> + if (conf->crypto_xform->type =3D=3D RTE_CRYPTO_SYM_XFORM_AEAD) {
> + if (!valid_aead_xform(iavf_sctx, &conf->crypto_xform->aead)) {
> + PMD_DRV_LOG(ERR, "Unsupported IPsec option specified");
> + return -EINVAL;
> + }
Invalid parameter, but not unsupported option, right? Same to below.
[...]
> +static void
> +sa_add_set_aead_params(struct virtchnl_ipsec_crypto_cfg_item *cfg,
> + struct rte_crypto_aead_xform *aead, uint32_t salt)
> +{
> + cfg->crypto_type =3D VIRTCHNL_AEAD;
> +
> + switch (aead->algo) {
> + case RTE_CRYPTO_AEAD_AES_CCM:
> + cfg->algo_type =3D VIRTCHNL_AES_CCM; break;
> + case RTE_CRYPTO_AEAD_AES_GCM:
> + cfg->algo_type =3D VIRTCHNL_AES_GCM; break;
> + case RTE_CRYPTO_AEAD_CHACHA20_POLY1305:
> + cfg->algo_type =3D VIRTCHNL_CHACHA20_POLY1305; break;
> + default:
> + RTE_ASSERT("we should be here");
Assert just because invalid config? Similar comments to other valid functio=
ns.
> + }
> +
> + cfg->key_len =3D aead->key.length;
> + cfg->iv_len =3D aead->iv.length;
> + cfg->digest_len =3D aead->digest_length;
> + cfg->salt =3D salt;
> +
> + RTE_ASSERT(sizeof(cfg->key_data) < cfg->key_len);
> +
Not only data, but length, better to valid before setting? The same to othe=
r kind params setting.
[...]
> +static inline void
> +iavf_build_data_desc_cmd_offset_fields(volatile uint64_t *qw1,
> + struct rte_mbuf *m)
> +{
> + uint64_t command =3D 0;
> + uint64_t offset =3D 0;
> + uint64_t l2tag1 =3D 0;
> +
> + *qw1 =3D IAVF_TX_DESC_DTYPE_DATA;
> +
> + command =3D (uint64_t)IAVF_TX_DESC_CMD_ICRC;
> +
> + /* Descriptor based VLAN insertion */
> + if (m->ol_flags & PKT_TX_VLAN_PKT) {
> + command |=3D (uint64_t)IAVF_TX_DESC_CMD_IL2TAG1;
> + l2tag1 |=3D m->vlan_tci;
> + }
> +
> /* Set MACLEN */
> - *td_offset |=3D (tx_offload.l2_len >> 1) <<
> - IAVF_TX_DESC_LENGTH_MACLEN_SHIFT;
> -
> - /* Enable L3 checksum offloads */
> - if (ol_flags & PKT_TX_IP_CKSUM) {
> - *td_cmd |=3D IAVF_TX_DESC_CMD_IIPT_IPV4_CSUM;
> - *td_offset |=3D (tx_offload.l3_len >> 2) <<
> - IAVF_TX_DESC_LENGTH_IPLEN_SHIFT;
> - } else if (ol_flags & PKT_TX_IPV4) {
> - *td_cmd |=3D IAVF_TX_DESC_CMD_IIPT_IPV4;
> - *td_offset |=3D (tx_offload.l3_len >> 2) <<
> - IAVF_TX_DESC_LENGTH_IPLEN_SHIFT;
> - } else if (ol_flags & PKT_TX_IPV6) {
> - *td_cmd |=3D IAVF_TX_DESC_CMD_IIPT_IPV6;
> - *td_offset |=3D (tx_offload.l3_len >> 2) <<
> - IAVF_TX_DESC_LENGTH_IPLEN_SHIFT;
> - }
> -
> - if (ol_flags & PKT_TX_TCP_SEG) {
> - *td_cmd |=3D IAVF_TX_DESC_CMD_L4T_EOFT_TCP;
> - *td_offset |=3D (tx_offload.l4_len >> 2) <<
> - IAVF_TX_DESC_LENGTH_L4_FC_LEN_SHIFT;
> - return;
PKT_TX_TCP_SEG flag implies PKT_TX_TCP_CKSUM,
so the offset cannot removed by just check cusm offload fields.
[...]
> struct iavf_32b_rx_flex_desc_comms {
> + union {
> + struct {
> /* Qword 0 */
> u8 rxdid;
> u8 mir_id_umb_cast;
> @@ -305,6 +375,101 @@ struct iavf_32b_rx_flex_desc_comms {
> } flex;
> __le32 ts_high;
> } flex_ts;
> + };
> + struct {
> + /* Quad Word 0 */
> +
> + u8 rxdid; /**< Descriptor builder profile ID */
> +
> + u8 mirror_id:6;
> + u8 umbcast:2;
> +
> + __le16 ptype:10;
> + __le16 flexi_flags_0:6;
> +
> + __le16 packet_length:14;
> + __le16 rsv_0:2;
> +
> + __le16 hlen:11;
> + __le16 sph:1;
> + __le16 flexi_flags_1:4;
> +
> + /* Quad Word 1 */
> + union {
> + __le16 status_error0;
> + struct {
> + __le16 status_error0_dd:1;
> + /* descriptor done */
> + __le16 status_error0_eop:1;
> + /* end of packet */
> + __le16 status_error0_hbo:1;
> + /* header buffer overflow */
> + __le16 status_error0_l3l4p:1;
> + /* l3/l4 integrity check */
> + __le16 status_error0_xsum:4;
> + /* checksum report */
> + __le16 status_error0_lpbk:1;
> + /* loopback */
> + __le16 status_error0_ipv6exadd:1;
> + /* ipv6 w/ dst options or routing hdr */
> + __le16 status_error0_rxe:1;
> + /* rcv mac errors */
> + __le16 status_error0_crcp:1;
> + /* ethernet crc present */
> + __le16 status_error0_rsshash:1;
> + /* rss hash valid */
> + __le16 status_error0_l2tag1p:1;
> + /* l2 tag 1 present */
> + __le16 status_error0_flexi_md0:1;
> + /* flexi md field 0 valid */
> + __le16 status_error0_flexi_md1:1;
> + /* flexi md field 1 valid */
> + };
> + };
> + __le16 l2tag1;
> + __le16 flex_meta0; /**< flexi metadata field 0 */
> + __le16 flex_meta1; /**< flexi metadata field 1 */
> +
> + /* Quad Word 2 */
> + union {
> + __le16 status_error1;
> + struct {
> + __le16 status_error1_cpm:4;
> + /* Inline IPsec Crypto Status */
> + __le16 status_error1_udp_tunnel:1;
> + /* UDP tunnelled packet NAT-T/UDP-NAT */
> + __le16 status_error1_crypto:1;
> + /* Inline IPsec Crypto Offload */
> + __le16 status_error1_rsv:5;
> + /* Reserved */
> + __le16 status_error1_l2tag2p:1;
> + /* l2 tag 2 present */
> + __le16 status_error1_flexi_md2:1;
> + /* flexi md field 2 valid */
> + __le16 status_error1_flexi_md3:1;
> + /* flexi md field 3 valid */
> + __le16 status_error1_flexi_md4:1;
> + /* flexi md field 4 valid */
> + __le16 status_error1_flexi_md5:1;
> + /* flexi md field 5 valid */
> + };
> + };
> +
> + u8 flex_flags2;
> + u8 time_stamp_low;
> +
> + __le16 l2tag2_1st; /**< L2TAG */
> + __le16 l2tag2_2nd; /**< L2TAG */
> +
> + /* Quad Word 3 */
> +
> + __le16 flex_meta2; /**< flexi metadata field 2 */
> + __le16 flex_meta3; /**< flexi metadata field 3 */
> + __le16 flex_meta4; /**< flexi metadata field 4 */
> + __le16 flex_meta5; /**< flexi metadata field 5 */
> +
> + } debug;
> + };
> };
If you check the description of this struct, you will find it is for RxDID =
Profile ID 16-21.
I think you need define a new struct for ipsec. And for debug, also prefer =
a new struct
or some func instead of adding union and fields in defined formatted descri=
ptor.=20
[....]
> +
> +#include <netinet/in.h>
> +
Put this inline at the beginning of file?
[...]
> @@ -330,18 +339,40 @@ iavf_handle_virtchnl_msg(struct rte_eth_dev *dev)
> case iavf_aqc_opc_send_msg_to_vf:
> if (msg_opc =3D=3D VIRTCHNL_OP_EVENT) {
> iavf_handle_pf_event_msg(dev, info.msg_buf,
> - info.msg_len);
> + info.msg_len);
> } else {
> + /* check for inline IPsec events */
> + struct inline_ipsec_msg *imsg =3D
> + (struct inline_ipsec_msg *)info.msg_buf;
> + struct rte_eth_event_ipsec_desc desc;
> + if (msg_opc =3D=3D VIRTCHNL_OP_INLINE_IPSEC_CRYPTO
> + && imsg->ipsec_opcode =3D=3D
> + INLINE_IPSEC_OP_EVENT) {
> + struct virtchnl_ipsec_event *ev =3D
> + imsg->ipsec_data.event;
> + desc.subtype =3D
> + RTE_ETH_EVENT_IPSEC_UNKNOWN;
> + desc.metadata =3D ev->ipsec_event_data;
> + rte_eth_dev_callback_process(dev,
> + RTE_ETH_EVENT_IPSEC,
> + &desc);
> + return;
> + }
> +
> /* read message and it's expected one */
> - if (msg_opc =3D=3D vf->pend_cmd)
> - _notify_cmd(vf, msg_ret);
> - else
> - PMD_DRV_LOG(ERR, "command mismatch,"
> - "expect %u, get %u",
> - vf->pend_cmd, msg_opc);
> + if (msg_opc =3D=3D vf->pend_cmd) {
> + rte_atomic32_dec(&vf->pend_cmd_count);
> + if (rte_atomic32_read(
> + &vf->pend_cmd_count) =3D=3D 0)
> + _notify_cmd(vf, msg_ret);
Only dec the count, does the async mean only the second message carries res=
ponse info?
[...]