From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0050.outbound.protection.outlook.com [104.47.2.50]) by dpdk.org (Postfix) with ESMTP id EF6B5DED for ; Mon, 29 Oct 2018 17:44:39 +0100 (CET) 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=N8UufvME3XR4rcd2k6uHx1kbRhQSDuBo6+ig6j0xKy4=; b=Ovb5+7Y5HPpAVYDDjbnOgKgrWBMfQsGibv/7YajTmsn0awGTVuMOOnvzN1xHcX3EHvBozqh7SD2Q06g18XbuXEe6UmhokBPThIVLXZsbB52Wh+h7j2Trp9dRpFuGrgIAkjHpHks984EtOQhhH/aAA0r7JGSYltuBSsUhPp72Z4Q= Received: from VI1PR05MB4224.eurprd05.prod.outlook.com (52.133.12.13) by VI1PR05MB4751.eurprd05.prod.outlook.com (20.176.4.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.21; Mon, 29 Oct 2018 16:44:37 +0000 Received: from VI1PR05MB4224.eurprd05.prod.outlook.com ([fe80::345d:803:9e2:679c]) by VI1PR05MB4224.eurprd05.prod.outlook.com ([fe80::345d:803:9e2:679c%4]) with mapi id 15.20.1273.027; Mon, 29 Oct 2018 16:44:37 +0000 From: Dekel Peled To: Shahaf Shuler , Yongseok Koh CC: "dev@dpdk.org" , Ori Kam Thread-Topic: [dpdk-dev] [PATCH v6 2/6] net/mlx5: add VXLAN encap action to Direct Verbs Thread-Index: AQHUbJ6vxA2fK3fnT0WiKU2TYnEJD6U2A/gAgABrFJA= Date: Mon, 29 Oct 2018 16:44:37 +0000 Message-ID: References: <1539259967-10975-1-git-send-email-dekelp@mellanox.com> <1540498108-18358-3-git-send-email-dekelp@mellanox.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dekelp@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR05MB4751; 6:OLWSZKXS4SZzqH4lmpsbWubXfPfabKXTM/N0IOdDvVA4IJuuLO7pTca4XxwJFX34dEYPwTESJW7nGFwlF9/Q3aLLEFNkR4bYsnIsPxdw+4II8SExZ99S9CbAqKrDQkbPL3MMb9CSxTYUsvmLcOe7LQg1SNFEeM/Xfw9mb78Wf8pg4e+bP1EnDTuFqkWv1Is7tdXGQwwBT/7IUTLVo5kn3n4lHBHAx/HA2lnvNKKOYVwramRkYbb8Wc4iM9fxvfDTMnacSQm/8hNwzoXmczdqxnbmGX3lAinxjXQAgcV8i57Z4Ilkwttc+Udf9i1+Gkhc4mrBCTEyk/wPVKYwAOuS+LxpZo+gbJjvrRVkPtrHD1ki6noQMxNYgmN0Y9I1gu3n76xpxzl1lT/aoJvsd25opjdoBolhYfA/zaHJBI5fGwmL07HbYxLwfFkl+ZR90vXElOoSGLJq62oTDNC8RPytkg==; 5:s5CwNqoQB6PR2z2799b2WtGFzUbhlnMPUDEMOdscFHZBtQjZ9NHhoBnsVkhJ8qjJnz5roQ8TsbHgLzyZjMiqr7XkDw8AZJWxL0Q0Iw5N4AqoLcWT1dMCupCkDIxXuiLqML/+kl3Ft9OsOaLtRDqVEy6LhREgwtx3w7FGU5o3DnI=; 7:3HLdGV140ilvyI6BorICOjjM8PooXo7N/SHeKWp3CB9k8rutETrzExTA/aLlZWp25J3LlOf1vkigvU6dLvQ8DR6vWhmTnEbFKzGkHKL1pym51puZCy9MwWJCZAfeW2SqLQ9dPr06+no7r+XA/pYx4Q== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 2d323cbc-6fd5-40c1-20ba-08d63dbdd08a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR05MB4751; x-ms-traffictypediagnostic: VI1PR05MB4751: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231382)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR05MB4751; BCL:0; PCL:0; RULEID:; SRVR:VI1PR05MB4751; x-forefront-prvs: 084080FC15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(136003)(396003)(39860400002)(366004)(199004)(189003)(13464003)(76176011)(55016002)(66066001)(256004)(25786009)(9686003)(14454004)(4744004)(486006)(476003)(14444005)(4326008)(81156014)(2906002)(478600001)(5660300001)(81166006)(99286004)(11346002)(6436002)(6636002)(446003)(68736007)(3846002)(7696005)(6116002)(229853002)(107886003)(54906003)(102836004)(105586002)(110136005)(53936002)(86362001)(97736004)(71200400001)(26005)(6246003)(74316002)(316002)(186003)(33656002)(7736002)(6506007)(71190400001)(305945005)(53546011)(8936002)(53946003)(106356001)(5250100002)(575784001)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB4751; H:VI1PR05MB4224.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Nt22wQZhnAvhWehYFxYvviMv4ciOCZHEQXYQp2k3dYFijs+I66z3IsquzXo0YtWgTkFixqZAWo9tLSY+NP6qRVE3eU3Lvu1FM7m5QLl5Jf/ffzVpYdeLnFSnaUC/hVb5Rnk3MQKruO08oUpoaiBbHbra3FRU+rzMGWPAKoRZ5foXwWV65Xpg65ibCprBB4JWgs/5ZqbNGa3VFoSujg5/8Bzmf9frBXYtw8w+AYMIK1Aux/zm5+wi5RNXE6d3N0jicMoeWrelVPcRabbyha0zAn1ozdEdO0Tr0iub5LfXutWbaoBKJiRLarHN5yQkkhpmKuA8fjDuzR9fciKpATDqf1aQgc4ZVdh/bIB+9sPUPLE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d323cbc-6fd5-40c1-20ba-08d63dbdd08a X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2018 16:44:37.5850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB4751 Subject: Re: [dpdk-dev] [PATCH v6 2/6] net/mlx5: add VXLAN encap action to Direct Verbs 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: , X-List-Received-Date: Mon, 29 Oct 2018 16:44:40 -0000 Thanks, PSB. > -----Original Message----- > From: Shahaf Shuler > Sent: Monday, October 29, 2018 12:03 PM > To: Dekel Peled ; Yongseok Koh > > Cc: dev@dpdk.org; Ori Kam > Subject: RE: [dpdk-dev] [PATCH v6 2/6] net/mlx5: add VXLAN encap action t= o > Direct Verbs >=20 > Hi Dekel, >=20 > Thursday, October 25, 2018 11:08 PM, Dekel Peled: > > Subject: [dpdk-dev] [PATCH v6 2/6] net/mlx5: add VXLAN encap action to > > Direct Verbs > > > > This patch implements the VXLAN encap action in DV flow for MLX5 PMD. > > > > Signed-off-by: Dekel Peled > > --- > > drivers/net/mlx5/mlx5_flow.h | 2 + > > drivers/net/mlx5/mlx5_flow_dv.c | 351 > > +++++++++++++++++++++++++++++++++++++++- > > 2 files changed, 348 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/net/mlx5/mlx5_flow.h > > b/drivers/net/mlx5/mlx5_flow.h index 61299d6..6e92afe 100644 > > --- a/drivers/net/mlx5/mlx5_flow.h > > +++ b/drivers/net/mlx5/mlx5_flow.h > > @@ -92,6 +92,7 @@ > > #define MLX5_FLOW_ACTION_DEC_TTL (1u << 19) #define > > MLX5_FLOW_ACTION_SET_MAC_SRC (1u << 20) #define > > MLX5_FLOW_ACTION_SET_MAC_DST (1u << 21) > > +#define MLX5_FLOW_ACTION_VXLAN_ENCAP (1u << 22) > > > > #define MLX5_FLOW_FATE_ACTIONS \ > > (MLX5_FLOW_ACTION_DROP | MLX5_FLOW_ACTION_QUEUE | > > MLX5_FLOW_ACTION_RSS) @@ -181,6 +182,7 @@ struct mlx5_flow_dv { > #ifdef > > HAVE_IBV_FLOW_DV_SUPPORT > > struct mlx5dv_flow_action_attr > > actions[MLX5_DV_MAX_NUMBER_OF_ACTIONS]; > > /**< Action list. */ > > + struct ibv_flow_action *verbs_action; /**< Verbs encap/decap >=20 > The ibv_flow_action is already part of a union inside > mlx5dv_flow_action_attr, why you need it separately? > I see also in the below code that you copy it from the action list to thi= s > specific field. Can you elaborate why? >=20 I added it to use when flow rule is removed, for easy access to the action = to destroy. I am now changing the code per 17.11 PR 876, adding cache of encap/decap ac= tions, so this member is no longer needed, and will be removed. > > object. > > +*/ > > #endif > > int actions_n; /**< number of actions. */ }; diff --git > > a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c > > index 8f729f4..14110c5 100644 > > --- a/drivers/net/mlx5/mlx5_flow_dv.c > > +++ b/drivers/net/mlx5/mlx5_flow_dv.c > > @@ -34,6 +34,12 @@ > > > > #ifdef HAVE_IBV_FLOW_DV_SUPPORT > > > > +/* > > + * Encap buf length, max: > > + * Eth:14/VLAN:8/IPv6:40/TCP:36/TUNNEL:20/Eth:14 >=20 > VLAN is 4B not 8B. which tunnel is for 20B? This is code I reused from 17.11, I will verify it. >=20 > > + */ > > +#define MLX5_ENCAP_MAX_LEN 132 > > + > > /** > > * Validate META item. > > * > > @@ -96,6 +102,300 @@ > > } > > > > /** > > + * Validate the L2 encap action. > > + * Used for VXLAN encap action. >=20 > No need for that. Later on you put more supported protocols. This is a > generic function for L2 encap validation. I will remove it. >=20 > > + * > > + * @param[in] action_flags > > + * Holds the actions detected until now. > > + * @param[in] action > > + * Pointer to the encap action. > > + * @param[in] attr > > + * Pointer to flow attributes > > + * @param[out] error > > + * Pointer to error structure. > > + * > > + * @return > > + * 0 on success, a negative errno value otherwise and rte_errno is s= et. > > + */ > > +static int > > +flow_dv_validate_action_l2_encap(uint64_t action_flags, > > + const struct rte_flow_action *action, > > + const struct rte_flow_attr *attr, > > + struct rte_flow_error *error) > > +{ > > + if (!(action->conf)) > > + return rte_flow_error_set(error, EINVAL, > > + RTE_FLOW_ERROR_TYPE_ACTION, > > action, > > + "configuration cannot be null"); > > + if (action_flags & MLX5_FLOW_ACTION_DROP) > > + return rte_flow_error_set(error, EINVAL, > > + RTE_FLOW_ERROR_TYPE_ACTION, > > NULL, > > + "can't drop and encap in same > > flow"); > > + if (action_flags & MLX5_FLOW_ACTION_VXLAN_ENCAP) > > + return rte_flow_error_set(error, EINVAL, > > + RTE_FLOW_ERROR_TYPE_ACTION, > > NULL, > > + "can only have a single encap" > > + " action in a flow"); > > + if (attr->ingress) > > + return rte_flow_error_set(error, ENOTSUP, > > + > > RTE_FLOW_ERROR_TYPE_ATTR_INGRESS, > > + NULL, > > + "encap action not supported for " > > + "ingress"); > > + return 0; > > +} > > + > > +/** > > + * Get the size of specific rte_flow_item_type > > + * > > + * @param[in] item_type > > + * Tested rte_flow_item_type. > > + * > > + * @return > > + * sizeof struct item_type, 0 if void or irrelevant. > > + */ > > +static size_t > > +flow_dv_get_item_len(const enum rte_flow_item_type item_type) { >=20 > Can we have this function as a macro? >=20 > #define flow_dv_get_item_len(t) (strncpm(t, VOID, 4) ? 0 : sizeof(struct > rte_flow_item_##t) >=20 > Usage: flow_dv_get_item_len(ETH) >=20 I will change it. >=20 > > + size_t retval; > > + > > + switch (item_type) { > > + case RTE_FLOW_ITEM_TYPE_ETH: > > + retval =3D sizeof(struct rte_flow_item_eth); > > + break; > > + case RTE_FLOW_ITEM_TYPE_VLAN: > > + retval =3D sizeof(struct rte_flow_item_vlan); > > + break; > > + case RTE_FLOW_ITEM_TYPE_IPV4: > > + retval =3D sizeof(struct rte_flow_item_ipv4); > > + break; > > + case RTE_FLOW_ITEM_TYPE_IPV6: > > + retval =3D sizeof(struct rte_flow_item_ipv6); > > + break; > > + case RTE_FLOW_ITEM_TYPE_UDP: > > + retval =3D sizeof(struct rte_flow_item_udp); > > + break; > > + case RTE_FLOW_ITEM_TYPE_TCP: > > + retval =3D sizeof(struct rte_flow_item_tcp); > > + break; > > + case RTE_FLOW_ITEM_TYPE_VXLAN: > > + retval =3D sizeof(struct rte_flow_item_vxlan); > > + break; > > + case RTE_FLOW_ITEM_TYPE_GRE: > > + retval =3D sizeof(struct rte_flow_item_gre); > > + break; > > + case RTE_FLOW_ITEM_TYPE_NVGRE: > > + retval =3D sizeof(struct rte_flow_item_nvgre); > > + break; > > + case RTE_FLOW_ITEM_TYPE_VXLAN_GPE: > > + retval =3D sizeof(struct rte_flow_item_vxlan_gpe); > > + break; > > + case RTE_FLOW_ITEM_TYPE_MPLS: > > + retval =3D sizeof(struct rte_flow_item_mpls); > > + break; > > + case RTE_FLOW_ITEM_TYPE_VOID: /* Fall through. */ > > + default: > > + retval =3D 0; > > + break; > > + } > > + return retval; > > +}; > > + > > +/** > > + * Convert the encap action data from rte_flow_item to raw buffer > > + * > > + * @param[in] item > > + * Pointer to rte_flow_item object. >=20 > Since it is an item list, "items" is preferable. I will rename it. >=20 > > + * @param[out] buf > > + * Pointer to the output buffer. > > + * @param[out] size > > + * Pointer to the output buffer size. > > + * @param[out] error > > + * Pointer to the error structure. > > + * > > + * @return > > + * 0 on success, a negative errno value otherwise and rte_errno is s= et. > > + */ > > +static int > > +flow_dv_convert_encap_data(const struct rte_flow_item *item, uint8_t > > *buf, > > + size_t *size, struct rte_flow_error *error) { > > + struct ether_hdr *eth =3D NULL; > > + struct vlan_hdr *vlan =3D NULL; > > + struct ipv4_hdr *ipv4 =3D NULL; > > + struct ipv6_hdr *ipv6 =3D NULL; > > + struct udp_hdr *udp =3D NULL; > > + struct vxlan_hdr *vxlan =3D NULL; > > + size_t len; > > + size_t temp_size =3D 0; > > + > > + if (!item) > > + return rte_flow_error_set(error, EINVAL, > > + RTE_FLOW_ERROR_TYPE_ACTION, > > + NULL, "invalid empty data"); > > + for (; item->type !=3D RTE_FLOW_ITEM_TYPE_END; item++) { > > + len =3D flow_dv_get_item_len(item->type); > > + if (len + temp_size > MLX5_ENCAP_MAX_LEN) > > + return rte_flow_error_set(error, EINVAL, > > + > > RTE_FLOW_ERROR_TYPE_ACTION, > > + (void *)item->type, > > + "invalid item length"); >=20 > It is not invalid item length, it is items total size is too big for enca= p. I will change it. >=20 > > + rte_memcpy((void *)&buf[temp_size], item->spec, len); > > + switch (item->type) { > > + case RTE_FLOW_ITEM_TYPE_ETH: > > + eth =3D (struct ether_hdr *)&buf[temp_size]; > > + break; > > + case RTE_FLOW_ITEM_TYPE_VLAN: > > + vlan =3D (struct vlan_hdr *)&buf[temp_size]; > > + if (!eth) > > + return rte_flow_error_set(error, EINVAL, > > + > > RTE_FLOW_ERROR_TYPE_ACTION, > > + (void *)item->type, > > + "eth header not found"); > > + if (!eth->ether_type) > > + eth->ether_type =3D > > RTE_BE16(ETHER_TYPE_VLAN); > > + break; > > + case RTE_FLOW_ITEM_TYPE_IPV4: > > + ipv4 =3D (struct ipv4_hdr *)&buf[temp_size]; > > + if (!vlan && !eth) > > + return rte_flow_error_set(error, EINVAL, > > + > > RTE_FLOW_ERROR_TYPE_ACTION, > > + (void *)item->type, > > + "neither eth nor vlan" > > + " header found"); > > + if (vlan && !vlan->eth_proto) > > + vlan->eth_proto =3D > > RTE_BE16(ETHER_TYPE_IPv4); > > + else if (eth && !eth->ether_type) > > + eth->ether_type =3D > > RTE_BE16(ETHER_TYPE_IPv4); > > + if (!ipv4->version_ihl) > > + ipv4->version_ihl =3D 0x45; > > + if (!ipv4->time_to_live) > > + ipv4->time_to_live =3D 0x40; >=20 > If no existing macro have those two above defined as ones. > There are few more places on this function related to this comment. I will change it. >=20 > > + break; > > + case RTE_FLOW_ITEM_TYPE_IPV6: > > + ipv6 =3D (struct ipv6_hdr *)&buf[temp_size]; > > + if (!vlan && !eth) > > + return rte_flow_error_set(error, EINVAL, > > + > > RTE_FLOW_ERROR_TYPE_ACTION, > > + (void *)item->type, > > + "neither eth nor vlan" > > + " header found"); > > + if (vlan && !vlan->eth_proto) > > + vlan->eth_proto =3D > > RTE_BE16(ETHER_TYPE_IPv6); > > + else if (eth && !eth->ether_type) > > + eth->ether_type =3D > > RTE_BE16(ETHER_TYPE_IPv6); > > + if (!ipv6->vtc_flow) > > + ipv6->vtc_flow =3D RTE_BE32(0x60000000); > > + if (!ipv6->hop_limits) > > + ipv6->hop_limits =3D 0xff; > > + break; > > + case RTE_FLOW_ITEM_TYPE_UDP: > > + udp =3D (struct udp_hdr *)&buf[temp_size]; > > + if (!ipv4 && !ipv6) > > + return rte_flow_error_set(error, EINVAL, > > + > > RTE_FLOW_ERROR_TYPE_ACTION, > > + (void *)item->type, > > + "ip header not found"); > > + if (ipv4 && !ipv4->next_proto_id) > > + ipv4->next_proto_id =3D IPPROTO_UDP; > > + else if (ipv6 && !ipv6->proto) > > + ipv6->proto =3D IPPROTO_UDP; > > + break; > > + case RTE_FLOW_ITEM_TYPE_VXLAN: > > + vxlan =3D (struct vxlan_hdr *)&buf[temp_size]; > > + if (!udp) > > + return rte_flow_error_set(error, EINVAL, > > + > > RTE_FLOW_ERROR_TYPE_ACTION, > > + (void *)item->type, > > + "udp header not found"); > > + if (!udp->dst_port) > > + udp->dst_port =3D > > RTE_BE16(MLX5_UDP_PORT_VXLAN); > > + if (!vxlan->vx_flags) > > + vxlan->vx_flags =3D RTE_BE32(0x08000000); > > + break; > > + case RTE_FLOW_ITEM_TYPE_VXLAN_GPE: > > + vxlan =3D (struct vxlan_hdr *)&buf[temp_size]; > > + if (!udp) > > + return rte_flow_error_set(error, EINVAL, > > + > > RTE_FLOW_ERROR_TYPE_ACTION, > > + (void *)item->type, > > + "udp header not found"); > > + if (!udp->dst_port) > > + udp->dst_port =3D > > + > > RTE_BE16(MLX5_UDP_PORT_VXLAN_GPE); > > + if (!vxlan->vx_flags) > > + vxlan->vx_flags =3D RTE_BE32(0x0c000003); >=20 > I would say you cannot set internally the next protocol. Only the user kn= ow > what it is. > I think in case VXLAN_GPE is set on the item list, the next_proto field i= s a > must, otherwise the rule should be rejected. I will verify it. >=20 > > + break; > > + case RTE_FLOW_ITEM_TYPE_GRE: > > + case RTE_FLOW_ITEM_TYPE_NVGRE: > > + if (!ipv4 && !ipv6) > > + return rte_flow_error_set(error, EINVAL, > > + > > RTE_FLOW_ERROR_TYPE_ACTION, > > + (void *)item->type, > > + "ip header not found"); > > + if (ipv4 && !ipv4->next_proto_id) > > + ipv4->next_proto_id =3D IPPROTO_GRE; > > + else if (ipv6 && !ipv6->proto) > > + ipv6->proto =3D IPPROTO_GRE; >=20 > This patch is for VXLAN, yet you add a GRE/NVGRE code block. It is better= to > add it on the subsequent patches adding this feature. >=20 I will move it to next patch. > Also you need to check if the user put the protocol type on the GRE heade= r. > Same as the VXLAN-GPE case, this is a must. >=20 I will add it. > > + break; > > + case RTE_FLOW_ITEM_TYPE_VOID: > > + break; > > + default: > > + return rte_flow_error_set(error, EINVAL, > > + > > RTE_FLOW_ERROR_TYPE_ACTION, > > + (void *)item->type, > > + "unsupported item type"); > > + break; > > + } > > + temp_size +=3D len; > > + } > > + *size =3D temp_size; > > + return 0; > > +} > > + > > +/** > > + * Convert L2 encap action to DV specification. > > + * Used for VXLAN encap action. >=20 > Same - no need to specific which exact protocols. I will remove it. >=20 > > + * > > + * @param[in] dev > > + * Pointer to rte_eth_dev structure. > > + * @param[in] action > > + * Pointer to action structure. > > + * @param[out] error > > + * Pointer to the error structure. > > + * > > + * @return > > + * Pointer to action on success, NULL otherwise and rte_errno is set= . > > + */ > > +static struct ibv_flow_action * > > +flow_dv_create_action_l2_encap(struct rte_eth_dev *dev, > > + const struct rte_flow_action *action, > > + struct rte_flow_error *error) { > > + struct ibv_flow_action *verbs_action =3D NULL; > > + const struct rte_flow_item *encap_data; > > + struct priv *priv =3D dev->data->dev_private; > > + uint8_t buf[MLX5_ENCAP_MAX_LEN]; > > + size_t size =3D 0; > > + int convert_result =3D 0; > > + > > + encap_data =3D ((const struct rte_flow_action_vxlan_encap *) > > + action->conf)->definition; > > + convert_result =3D flow_dv_convert_encap_data(encap_data, buf, > > + &size, error); > > + if (convert_result) > > + return NULL; > > + verbs_action =3D mlx5_glue- > > >dv_create_flow_action_packet_reformat > > + (priv->ctx, size, (size ? buf : NULL), >=20 > How can size be 0 and yet the encap action is valid? It can't, this is just for safety. I will remove it. >=20 > > + > > MLX5DV_FLOW_ACTION_PACKET_REFORMAT_TYPE_L2_TO_L2_TUNNEL, > > + MLX5DV_FLOW_TABLE_TYPE_NIC_TX); > > + if (!verbs_action) > > + rte_flow_error_set(error, EINVAL, > > RTE_FLOW_ERROR_TYPE_ACTION, > > + NULL, "cannot create L2 encap action"); > > + return verbs_action; > > +} > > + > > +/** > > * Verify the @p attributes will be correctly understood by the NIC an= d > store > > * them in the @p flow if everything is correct. > > * > > @@ -339,6 +639,16 @@ > > action_flags |=3D MLX5_FLOW_ACTION_COUNT; > > ++actions_n; > > break; > > + case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP: > > + ret =3D > > flow_dv_validate_action_l2_encap(action_flags, > > + actions, attr, > > + error); > > + if (ret < 0) > > + return ret; > > + action_flags |=3D > > MLX5_FLOW_ACTION_VXLAN_ENCAP; > > + ++actions_n; > > + break; > > + > > default: > > return rte_flow_error_set(error, ENOTSUP, > > > > RTE_FLOW_ERROR_TYPE_ACTION, > > @@ -1045,14 +1355,26 @@ > > /** > > * Store the requested actions in an array. > > * > > + * @param[in] dev > > + * Pointer to rte_eth_dev structure. > > * @param[in] action > > * Flow action to translate. > > * @param[in, out] dev_flow > > * Pointer to the mlx5_flow. > > + * @param[in] attr > > + * Pointer to the flow attributes. > > + * @param[out] error > > + * Pointer to the error structure. > > + * > > + * @return > > + * 0 on success, a negative errno value otherwise and rte_errno is s= et. > > */ > > -static void > > -flow_dv_create_action(const struct rte_flow_action *action, > > - struct mlx5_flow *dev_flow) > > +static int > > +flow_dv_create_action(struct rte_eth_dev *dev, > > + const struct rte_flow_action *action, > > + struct mlx5_flow *dev_flow, > > + const struct rte_flow_attr *attr __rte_unused, >=20 > It was better to add this when you add the RAW encap feature. Now they > marked as unused, and you didn't changed that when you actually started t= o > use them. > Need to choose one of the paths: > 1. add them on the RAW encap/decap support (better) 2. remove the > rte_unused on the RAW encap/decap support >=20 I will move it to later patch. >=20 > > + struct rte_flow_error *error) > > { > > const struct rte_flow_action_queue *queue; > > const struct rte_flow_action_rss *rss; @@ -1100,10 +1422,24 @@ > > /* Added to array only in apply since we need the QP */ > > flow->actions |=3D MLX5_FLOW_ACTION_RSS; > > break; > > + case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP: > > + dev_flow->dv.actions[actions_n].type =3D > > + MLX5DV_FLOW_ACTION_IBV_FLOW_ACTION; > > + dev_flow->dv.actions[actions_n].action =3D > > + flow_dv_create_action_l2_encap(dev, > > action, > > + error); > > + if (!(dev_flow->dv.actions[actions_n].action)) > > + return -rte_errno; > > + dev_flow->dv.verbs_action =3D > > + dev_flow->dv.actions[actions_n].action; > > + flow->actions |=3D MLX5_FLOW_ACTION_VXLAN_ENCAP; > > + actions_n++; > > + break; > > default: > > break; > > } > > dev_flow->dv.actions_n =3D actions_n; > > + return 0; > > } > > > > static uint32_t matcher_zero[MLX5_ST_SZ_DW(fte_match_param)] =3D { 0 }= ; > > @@ -1217,7 +1553,6 @@ > > return 0; > > } > > > > - > > /** > > * Fill the flow with DV spec. > > * > > @@ -1272,7 +1607,8 @@ > > if (flow_dv_matcher_register(dev, &matcher, dev_flow, error)) > > return -rte_errno; > > for (; actions->type !=3D RTE_FLOW_ACTION_TYPE_END; actions++) > > - flow_dv_create_action(actions, dev_flow); > > + if (flow_dv_create_action(dev, actions, dev_flow, attr, > > error)) > > + return -rte_errno; > > return 0; > > } > > > > @@ -1457,6 +1793,11 @@ > > LIST_REMOVE(dev_flow, next); > > if (dev_flow->dv.matcher) > > flow_dv_matcher_release(dev, dev_flow); > > + if (dev_flow->dv.verbs_action) { >=20 > Like I said in the beginning, I don't understand why this field is separa= te from > the mlx5dv action list. >=20 > > + claim_zero(mlx5_glue->destroy_flow_action > > + (dev_flow- > > >dv.verbs_action)); > > + dev_flow->dv.verbs_action =3D NULL; > > + } > > rte_free(dev_flow); > > } > > } > > -- > > 1.8.3.1