From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20070.outbound.protection.outlook.com [40.107.2.70]) by dpdk.org (Postfix) with ESMTP id 66C662F4F for ; Mon, 29 Oct 2018 11:03:16 +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=AWLBLdtKelnYXATqJwInlYVCAmO21bZRgI00kp7k2jE=; b=hRUCChMUl1JnrAriwIGFk05O3yXki3OfIa1SDVWzPM7xF/xbhUg4kjWyCb7r0kjB3rSf+1f6pHinUYTo9Y467ZC1Qj0OQsnB7dge2geus+1fG7GQVilTp2/sOjXRUStvnb+CLEN10qxwbuSBogJgCOGX7jNC6U8+GLZFKhXr9Qk= Received: from DB7PR05MB4426.eurprd05.prod.outlook.com (52.134.109.15) by DB7PR05MB4428.eurprd05.prod.outlook.com (52.134.109.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.26; Mon, 29 Oct 2018 10:03:14 +0000 Received: from DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::80e:e6b:baf2:d973]) by DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::80e:e6b:baf2:d973%3]) with mapi id 15.20.1273.027; Mon, 29 Oct 2018 10:03:14 +0000 From: Shahaf Shuler To: Dekel Peled , 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: AQHUbJ6vFOFdRGz8/EyqGsDOTEC8XaU1xP9w Date: Mon, 29 Oct 2018 10:03:14 +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: <1540498108-18358-3-git-send-email-dekelp@mellanox.com> 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=shahafs@mellanox.com; x-originating-ip: [31.154.10.105] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR05MB4428; 6:f9j5vuc+EU2OgTsHYrWwlggfhA4oP+N0DrJZIWOmQWimr+Hie76b9/nUHA4e+3jtYfdRC4Xwkerhava8EFNPXovjJYV8E6chy6bfceDAHgx57RRW2+96XFpUd8R7VbKqaDX1ErqY06qYd0NfTUdtHgMecVJ/rksfasFdCPiP5k5SmmVqkgEYQYhMarwEbcDIrhdo4Q2ciUujBg2Gj/XpS4UvW4QE+vssFTUKg6hve1akm3kNwzOfviUHbTcSRCwubjDsrNAkgBDfjdrzx3v5rvKn1gNkNO9USbV/S3diV5rvO/kMK44ob/Av8k6l4CgdP16U+ZtSURihMFaOTroGlIwdjPyJ6cWOM/wf7OoqIrUoACU9zSyYvH2H8BfZgFwNHBckVR+0IbjVzpbiNGcjJAIWAWse+gMKaC93Sf7pcLai8xzrsUXx6jMVW1TNBeMom1Hkm+FTevixmdtTwQzx4Q==; 5:XNteZTZDgG+9WnR9z7lvl/2SZpr+KfIYGMGqA77inthgDtV6xs9WgQ2Ou+ZUJM6oMa2CQCwaNg4xrf/vab4q2P20LzNi8a1KnYvARRKvFsbDenuuf2F9KkPFGE8kQdk1Zw5dIgWaHSc4VEMNTsQeF4Q6VrYvPsbXWoSfbChwxNg=; 7:Qx5yWW49AJH6RZQnyfKOBjaaHdtHbw5ubXZXClEqwoqXkI2Jvo+x20EM/o4wi9hRC1fA7IoBCOjgg50/sjssOasVn1KUJp/Ck3/mE0yCZdVseuMoH8NdcM3YCBl2yZIDcwqNVXNed6siDmA9nlBehA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 2ea41495-eb9b-4550-e041-08d63d85be13 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB7PR05MB4428; x-ms-traffictypediagnostic: DB7PR05MB4428: 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)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:DB7PR05MB4428; BCL:0; PCL:0; RULEID:; SRVR:DB7PR05MB4428; x-forefront-prvs: 084080FC15 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(366004)(376002)(346002)(199004)(189003)(5250100002)(86362001)(66066001)(81166006)(81156014)(107886003)(575784001)(6436002)(8936002)(229853002)(25786009)(6116002)(3846002)(99286004)(26005)(14444005)(256004)(186003)(14454004)(53936002)(305945005)(11346002)(4326008)(105586002)(5660300001)(53946003)(110136005)(102836004)(486006)(76176011)(9686003)(446003)(33656002)(55016002)(97736004)(7736002)(7696005)(106356001)(2906002)(74316002)(4744004)(2900100001)(478600001)(6636002)(6506007)(68736007)(476003)(54906003)(6246003)(316002)(71190400001)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR05MB4428; H:DB7PR05MB4426.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: FhMSfpA4j+0gWd9DkvYffQ/V4PnYKRK2y3lNMfFm5LBKvUyR4xeoKn5vCGezSIjZaKz2w0BKmJnvEvwOXHLiedz5BkwzRBQNVK3lL4TouW00qnYq31dNg+X5V4TUedxbEPx1nGuqxjUPItgKYs1+or23wtbLmUT9PV5qwDN8JjiudwhvmAJIHrDICSbs42Ztg0xnw8mXG8TWVuCjT5f5wM02XypxlP4lULItrKtsuUq69X/vvbitPLDlNDJxYQ57/2d29ISELwQCpiVdL7seDp8UjMh5vhI5Ptng1w4yETInlGUz9HH7R+6eSM4kssPx+86pejvtahZqkBlAmUQrdFI7jgdZihGg5Tfl5e9ySkk= 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: 2ea41495-eb9b-4550-e041-08d63d85be13 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2018 10:03:14.6450 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR05MB4428 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 10:03:16 -0000 Hi Dekel, 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 >=20 > This patch implements the VXLAN encap action in DV flow for MLX5 PMD. >=20 > 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(-) >=20 > 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) >=20 > #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 The ibv_flow_action is already part of a union inside mlx5dv_flow_action_at= tr, why you need it separately?=20 I see also in the below code that you copy it from the action list to this = specific field. Can you elaborate why?=20 > 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 @@ >=20 > #ifdef HAVE_IBV_FLOW_DV_SUPPORT >=20 > +/* > + * Encap buf length, max: > + * Eth:14/VLAN:8/IPv6:40/TCP:36/TUNNEL:20/Eth:14 VLAN is 4B not 8B. which tunnel is for 20B?=20 > + */ > +#define MLX5_ENCAP_MAX_LEN 132 > + > /** > * Validate META item. > * > @@ -96,6 +102,300 @@ > } >=20 > /** > + * Validate the L2 encap action. > + * Used for VXLAN encap action. No need for that. Later on you put more supported protocols. This is a gene= ric function for L2 encap validation.=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 set= . > + */ > +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) { Can we have this function as a macro? #define flow_dv_get_item_len(t) (strncpm(t, VOID, 4) ? 0 : sizeof(struct rt= e_flow_item_##t) Usage: flow_dv_get_item_len(ETH) > + 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. Since it is an item list, "items" is preferable.=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 set= . > + */ > +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"); It is not invalid item length, it is items total size is too big for encap.= =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; If no existing macro have those two above defined as ones.=20 There are few more places on this function related to this comment.=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); I would say you cannot set internally the next protocol. Only the user know= what it is.=20 I think in case VXLAN_GPE is set on the item list, the next_proto field is = a must, otherwise the rule should be rejected.=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; This patch is for VXLAN, yet you add a GRE/NVGRE code block. It is better t= o add it on the subsequent patches adding this feature.=20 Also you need to check if the user put the protocol type on the GRE header.= Same as the VXLAN-GPE case, this is a must.=20 > + 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. Same - no need to specific which exact protocols.=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), How can size be 0 and yet the encap action is valid?=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 and = 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, >=20 > 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 set= . > */ > -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, It was better to add this when you add the RAW encap feature. Now they mark= ed as unused, and you didn't changed that when you actually started to 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 > + 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; > } >=20 > static uint32_t matcher_zero[MLX5_ST_SZ_DW(fte_match_param)] =3D { 0 }; > @@ -1217,7 +1553,6 @@ > return 0; > } >=20 > - > /** > * 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; > } >=20 > @@ -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) { Like I said in the beginning, I don't understand why this field is separate= 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