From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10078.outbound.protection.outlook.com [40.107.1.78]) by dpdk.org (Postfix) with ESMTP id 6441E5699 for ; Fri, 26 Oct 2018 06:22:03 +0200 (CEST) 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=yN8AM9xzUTAT6709vzZPjWnswIx7Ux25JSf451KjmKs=; b=G+F/LN6xuRTIILccKqCsVrd1q8xD95x7F5AIT4TrzaaSmBpx2xI3CrOBUPSZnLt3ENEsewwulET+aEjmhD/jNM+0ZgkW0m8qE9pAnOYCgpvLQDhAYcFO9DPgUpjQpgZFFoT9keDmVhyjwCqZeIo9UH6cE5Bu9xT7fbNpjylsa3A= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4074.eurprd05.prod.outlook.com (52.134.72.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.30; Fri, 26 Oct 2018 04:22:01 +0000 Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::f8a1:fcab:94f0:97cc]) by DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::f8a1:fcab:94f0:97cc%4]) with mapi id 15.20.1273.021; Fri, 26 Oct 2018 04:22:01 +0000 From: Yongseok Koh To: Slava Ovsiienko CC: Shahaf Shuler , "dev@dpdk.org" Thread-Topic: [PATCH v2 3/7] net/mlx5: e-switch VXLAN flow translation routine Thread-Index: AQHUZJFZmoxzpCFrNk+Iuvz4Vcwsm6UsMZyAgAPl5ACAAOY1gA== Date: Fri, 26 Oct 2018 04:22:01 +0000 Message-ID: <20181026042151.GC6434@mtidpdk.mti.labs.mlnx> References: <1538461807-37507-1-git-send-email-viacheslavo@mellanox.com> <1539612815-47199-1-git-send-email-viacheslavo@mellanox.com> <1539612815-47199-4-git-send-email-viacheslavo@mellanox.com> <20181023100621.GC14792@mtidpdk.mti.labs.mlnx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: BYAPR02CA0044.namprd02.prod.outlook.com (2603:10b6:a03:54::21) To DB3PR0502MB3980.eurprd05.prod.outlook.com (2603:10a6:8:10::27) authentication-results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [209.116.155.178] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0502MB4074; 6:JI9GdtiUfjYM84kJS2e7VzC4jNFfT65ICWJ8hMr3eBMzydhpg21pEOONH6YsiruFjkv95GN8JNfOeOF41WwBCkPba4mmKOLkNpVuugyTwi3WFaZsdcT2g+J/VsB8wfEjR4QUb7ZOIBlC1CifcJn4a+4EgNAR0q3b9QS0zUtmLRq7QdZ1oR2aTnGPzOXCwbcXaOFDuhsRkeuKPASwKBkJoeqgbWf98lqCDpAg/939QnKR+iJWQxNt5o503HtsxKSyuNvEaRseWf0dBnovQPQ0WlR4iZzdqt9imYxobxjRbAm3XK5Er5aBhURiuXkI99vqoKCghLAjS8Fh0MRLJUK9e6ly5uROWuW7UXYbiM3Ns40e7dOYevR3bY9zniuWtrQkc0noihe3Zlvg8ePq1ql2G+ejO5HcO7MW8fiICesX2IgQl2fJ10rIw4BYFrufz6TsV5aFv/fAmvsBcGstFgxQew==; 5:V5Pb9LKCM0Hel62QQn7daPJiVzTLdJpEJtF0pUz2nszfTAntAqwP9JJ6SKWRFpk+QDolsuJnB7H247HhzWkRdGaaBoClBAQ0RzPSaep2P7WzdpDpNR6nEIx3C4ma5OAjG/sVKYOGjaCk08s3b4tVYhK7zCVpsp4W3PFENPmnMaI=; 7:fxzqJ65hE+xWTznTuD1ry7DtwRkJb83Z3OVzwWAN5xAcdwFXapKiESTU1zjbsAFsczdHMPyy9QqwTx/b93qQsYw8zLWEcYK/FvlbrNc1zBQjc3W099ZBLXxoXRDPsz5BgbINHVKMECCVQzrlbaznl8yrc1O7AGWven/YXbmZNEK9EbVLsNoCxQiZJ8LtioOop3LoovnYAI4oDjC6VrsuGg7pIgkvJ7VfDziP8tbnsYiR0OCFlrnW3Qv8WdKx+mDR x-ms-office365-filtering-correlation-id: 2a4cddf3-eac9-4a33-66d6-08d63afa935a 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:DB3PR0502MB4074; x-ms-traffictypediagnostic: DB3PR0502MB4074: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231355)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB3PR0502MB4074; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0502MB4074; x-forefront-prvs: 083751FCA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(376002)(346002)(366004)(39860400002)(136003)(396003)(199004)(189003)(13464003)(52314003)(71200400001)(2900100001)(33656002)(2906002)(99286004)(71190400001)(68736007)(5660300001)(26005)(81166006)(81156014)(386003)(53546011)(102836004)(14454004)(316002)(54906003)(14444005)(256004)(186003)(478600001)(6506007)(8676002)(33896004)(93886005)(8936002)(52116002)(66066001)(86362001)(6862004)(1076002)(5250100002)(7736002)(53936002)(4326008)(446003)(229853002)(305945005)(11346002)(476003)(76176011)(9686003)(6512007)(6116002)(3846002)(6636002)(97736004)(486006)(4744004)(6436002)(106356001)(6486002)(6246003)(25786009)(105586002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4074; H:DB3PR0502MB3980.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: tR9INwb3rX77mVJ3o8Ax8gUBjsULnq/CYeOJNEyzvQ3QdO7q3oj5aUuWpt6llNvRsZlJY0UEQx4VH11+vAFIYPH8Z8XjXaCc0gY7IZRT0Beqd+ELY74XFmfP9DCms70aptsdp66TzBr5VsZ3dmZWaM5WI7rfQNs8/GwzYtRKcaZuzooYdq/lRzYYCgmG5lBzsWnNIz5UKNEr4U7ynifNXe5tJTjzI7aXPnXpYcJICCx1Z5vjx4K+M513Yr/suxg1HrHP/CXAz9ofwDKEWTsy83x8A5IyVt0Q5rCaCuyD/6MGUTc7FRokfOXwicsXwy/ByZwVNW3WU/D1wOn818TdXQFKjPMnswVfIY9Qr0MSZac= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <4BE0CDC4A389F941A597C603FDB14657@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a4cddf3-eac9-4a33-66d6-08d63afa935a X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2018 04:22:01.1376 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0502MB4074 Subject: Re: [dpdk-dev] [PATCH v2 3/7] net/mlx5: e-switch VXLAN flow translation routine 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: Fri, 26 Oct 2018 04:22:04 -0000 On Thu, Oct 25, 2018 at 07:37:56AM -0700, Slava Ovsiienko wrote: > > -----Original Message----- > > From: Yongseok Koh > > Sent: Tuesday, October 23, 2018 13:06 > > To: Slava Ovsiienko > > Cc: Shahaf Shuler ; dev@dpdk.org > > Subject: Re: [PATCH v2 3/7] net/mlx5: e-switch VXLAN flow translation > > routine > >=20 > > On Mon, Oct 15, 2018 at 02:13:31PM +0000, Viacheslav Ovsiienko wrote: [...] > > > @@ -2184,13 +2447,16 @@ struct pedit_parser { > > > * Pointer to the list of actions. > > > * @param[out] action_flags > > > * Pointer to the detected actions. > > > + * @param[out] tunnel > > > + * Pointer to tunnel encapsulation parameters structure to fill. > > > * > > > * @return > > > * Maximum size of memory for actions. > > > */ > > > static int > > > flow_tcf_get_actions_and_size(const struct rte_flow_action actions[]= , > > > - uint64_t *action_flags) > > > + uint64_t *action_flags, > > > + void *tunnel) > >=20 > > This func is to get actions and size but you are parsing and filling tu= nnel info > > here. It would be better to move parsing to translate() because it anyw= ay has > > multiple if conditions (same as switch/case) to set TCA_TUNNEL_KEY_ENC_= * > > there. > Do you mean call of flow_tcf_vxlan_encap_parse(actions, tunnel)? Yes. > OK, let's move it to translate stage. Anyway, we need to keep encap struc= ture > for local/neigh rules. >=20 > >=20 > > > { > > > int size =3D 0; > > > uint64_t flags =3D 0; > > > @@ -2246,6 +2512,29 @@ struct pedit_parser { > > > SZ_NLATTR_TYPE_OF(uint16_t) + /* VLAN ID. > > */ > > > SZ_NLATTR_TYPE_OF(uint8_t); /* VLAN prio. > > */ > > > break; > > > + case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP: > > > + size +=3D SZ_NLATTR_NEST + /* na_act_index. */ > > > + SZ_NLATTR_STRZ_OF("tunnel_key") + > > > + SZ_NLATTR_NEST + /* TCA_ACT_OPTIONS. > > */ > > > + SZ_NLATTR_TYPE_OF(uint8_t); > > > + size +=3D SZ_NLATTR_TYPE_OF(struct tc_tunnel_key); > > > + size +=3D flow_tcf_vxlan_encap_parse(actions, tunnel) > > + > > > + RTE_ALIGN_CEIL /* preceding encap params. > > */ > > > + (sizeof(struct mlx5_flow_tcf_vxlan_encap), > > > + MNL_ALIGNTO); > >=20 > > Is it different from SZ_NLATTR_TYPE_OF(struct > > mlx5_flow_tcf_vxlan_encap)? Or, use __rte_aligned(MNL_ALIGNTO) instead. >=20 > It is written intentionally in this form. It means that there is struct m= lx5_flow_tcf_vxlan_encap=20 > at the beginning of buffer. This is not the NL attribute, usage of SZ_NLA= TTR_TYPE_OF is > not relevant here. Alignment is needed for the following Netlink message. Good point. Understood. > >=20 > > > + flags |=3D MLX5_ACTION_VXLAN_ENCAP; > > > + break; > > > + case RTE_FLOW_ACTION_TYPE_VXLAN_DECAP: > > > + size +=3D SZ_NLATTR_NEST + /* na_act_index. */ > > > + SZ_NLATTR_STRZ_OF("tunnel_key") + > > > + SZ_NLATTR_NEST + /* TCA_ACT_OPTIONS. > > */ > > > + SZ_NLATTR_TYPE_OF(uint8_t); > > > + size +=3D SZ_NLATTR_TYPE_OF(struct tc_tunnel_key); > > > + size +=3D RTE_ALIGN_CEIL /* preceding decap params. > > */ > > > + (sizeof(struct mlx5_flow_tcf_vxlan_decap), > > > + MNL_ALIGNTO); > >=20 > > Same here. > >=20 > > > + flags |=3D MLX5_ACTION_VXLAN_DECAP; > > > + break; > > > case RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC: > > > case RTE_FLOW_ACTION_TYPE_SET_IPV4_DST: > > > case RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC: > > > @@ -2289,6 +2578,26 @@ struct pedit_parser { } > > > > > > /** > > > + * Convert VXLAN VNI to 32-bit integer. > > > + * > > > + * @param[in] vni > > > + * VXLAN VNI in 24-bit wire format. > > > + * > > > + * @return > > > + * VXLAN VNI as a 32-bit integer value in network endian. > > > + */ > > > +static rte_be32_t > >=20 > > make it inline. > OK. Missed point. >=20 > >=20 > > > +vxlan_vni_as_be32(const uint8_t vni[3]) { > > > + rte_be32_t ret; > >=20 > > Defining ret as rte_be32_t? The return value of this func which is bswa= p(ret) > > is also rte_be32_t?? > Yes. And it is directly stored in the net-endian NL attribute.=20 > I've compiled and checked the listing of the function you proposed. It se= ems to be best, I'll take it. >=20 > >=20 > > > + > > > + ret =3D vni[0]; > > > + ret =3D (ret << 8) | vni[1]; > > > + ret =3D (ret << 8) | vni[2]; > > > + return RTE_BE32(ret); > >=20 > > Use rte_cpu_to_be_*() instead. But I still don't understand why you shu= ffle > > bytes twice. One with shift and or and other by bswap(). > And it works. There are three bytes in very bizarre order (in NL attribut= e) - 0, vni[0], vni[1], vni[2]. >=20 > >=20 > > { > > union { > > uint8_t vni[4]; > > rte_be32_t dword; > > } ret =3D { > > .vni =3D { 0, vni[0], vni[1], vni[2] }, > > }; > > return ret.dword; > > } > >=20 > > This will have the same result without extra cost. >=20 > OK. Investigated, it is the best for x86-64. Also I'm going to test it on= the ARM 32, > with various compilers, just curious. >=20 > >=20 > > > +} > > > + > > > +/** > > > * Prepare a flow object for Linux TC flower. It calculates the maxi= mum > > size of > > > * memory required, allocates the memory, initializes Netlink messag= e > > headers > > > * and set unique TC message handle. > > > @@ -2323,22 +2632,54 @@ struct pedit_parser { > > > struct mlx5_flow *dev_flow; > > > struct nlmsghdr *nlh; > > > struct tcmsg *tcm; > > > + struct mlx5_flow_tcf_vxlan_encap encap =3D {.mask =3D 0}; > > > + uint8_t *sp, *tun =3D NULL; > > > > > > size +=3D flow_tcf_get_items_and_size(attr, items, item_flags); > > > - size +=3D flow_tcf_get_actions_and_size(actions, action_flags); > > > - dev_flow =3D rte_zmalloc(__func__, size, MNL_ALIGNTO); > > > + size +=3D flow_tcf_get_actions_and_size(actions, action_flags, > > &encap); > > > + dev_flow =3D rte_zmalloc(__func__, size, > > > + RTE_MAX(alignof(struct mlx5_flow_tcf_tunnel_hdr), > > > + (size_t)MNL_ALIGNTO)); > >=20 > > Why RTE_MAX between the two? Note that it is alignment for start addres= s > > of the memory and the minimum alignment is cacheline size. On x86, non- > > zero value less than 64 will have same result as 64. >=20 > OK. Thanks for note. > It is not expected the structure alignments exceed the cache line size. > So? Just specify zero? > >=20 > > > if (!dev_flow) { > > > rte_flow_error_set(error, ENOMEM, > > > RTE_FLOW_ERROR_TYPE_UNSPECIFIED, > > NULL, > > > "not enough memory to create E-Switch > > flow"); > > > return NULL; > > > } > > > - nlh =3D mnl_nlmsg_put_header((void *)(dev_flow + 1)); > > > + sp =3D (uint8_t *)(dev_flow + 1); > > > + if (*action_flags & MLX5_ACTION_VXLAN_ENCAP) { > > > + tun =3D sp; > > > + sp +=3D RTE_ALIGN_CEIL > > > + (sizeof(struct mlx5_flow_tcf_vxlan_encap), > > > + MNL_ALIGNTO); > >=20 > > And why should it be aligned?=20 >=20 > Netlink message should be aligned. It follows the mlx5_flow_tcf_vxlan_enc= ap, > that's why the pointer is aligned. Not true. There's no requirement for nl msg buffer alignment. MNL_ALIGNTO i= s for mainly size alignment. For example, checkout the source code of mnl_nlmsg_put_header(void *buf). There's no requirement of aligning the sta= rt address of buf. But, size of any entries (hdr, attr ...) should be aligned = to MNL_ALIGNTO(4). >=20 > As the size of dev_flow might not be aligned, it > > is meaningless, isn't it? If you think it must be aligned for better pe= rformance > > (not much anyway), you can use __rte_aligned(MNL_ALIGNTO) on the struct > Hm. Where we can use __rte_aligned? Could you clarify, please. For example, struct mlx5_flow_tcf_tunnel_hdr { uint32_t type; /**< Tunnel action type. */ unsigned int ifindex_tun; /**< Tunnel endpoint interface. */ unsigned int ifindex_org; /**< Original dst/src interface */ unsigned int *ifindex_ptr; /**< Interface ptr in message. */ } __rte_aligned(MNL_ALIGNTO); A good example is the struct rte_mbuf. If this attribute is used, the size = of the struct will be aligned to the value. If you still want to make the nl msg aligned, dev_flow =3D rte_zmalloc(..., MNL_ALIGNTO); /* anyway cacheline aligned. *= / tun =3D RTE_PTR_ALIGN(dev_flow + 1, MNL_ALIGNTO); nlh =3D mnl_nlmsg_put_header(tun); with adding '__rte_aligned(MNL_ALIGNTO)' to struct mlx5_flow_tcf_vxlan_enca= p/decap. Then, nlh will be aligned. You should make sure size is correctly calculate= d. >=20 > > definition but not for mlx5_flow (it's not only for tcf, have to do it = manually). > >=20 > > > + size -=3D RTE_ALIGN_CEIL > > > + (sizeof(struct mlx5_flow_tcf_vxlan_encap), > > > + MNL_ALIGNTO); > >=20 > > Don't you have to subtract sizeof(struct mlx5_flow) as well? But like I > > mentioned, if '.nlsize' below isn't needed, you don't need to have this > > calculation either. > Yes, it is a bug. Should be fixed. Thank you. > Let's discuss whether we can keep the nlsize under NDEBUG switch. I agreed on using NDEBUG for it. >=20 > >=20 > > > + encap.hdr.type =3D > > MLX5_FLOW_TCF_TUNACT_VXLAN_ENCAP; > > > + memcpy(tun, &encap, > > > + sizeof(struct mlx5_flow_tcf_vxlan_encap)); > > > + } else if (*action_flags & MLX5_ACTION_VXLAN_DECAP) { > > > + tun =3D sp; > > > + sp +=3D RTE_ALIGN_CEIL > > > + (sizeof(struct mlx5_flow_tcf_vxlan_decap), > > > + MNL_ALIGNTO); > > > + size -=3D RTE_ALIGN_CEIL > > > + (sizeof(struct mlx5_flow_tcf_vxlan_decap), > > > + MNL_ALIGNTO); > > > + encap.hdr.type =3D > > MLX5_FLOW_TCF_TUNACT_VXLAN_DECAP; > > > + memcpy(tun, &encap, > > > + sizeof(struct mlx5_flow_tcf_vxlan_decap)); > > > + } > > > + nlh =3D mnl_nlmsg_put_header(sp); > > > tcm =3D mnl_nlmsg_put_extra_header(nlh, sizeof(*tcm)); > > > *dev_flow =3D (struct mlx5_flow){ > > > .tcf =3D (struct mlx5_flow_tcf){ > > > + .nlsize =3D size, > > > .nlh =3D nlh, > > > .tcm =3D tcm, > > > + .tunnel =3D (struct mlx5_flow_tcf_tunnel_hdr *)tun, > > > + .item_flags =3D *item_flags, > > > + .action_flags =3D *action_flags, > > > }, > > > }; > > > /* [...] > > > @@ -2827,6 +3268,76 @@ struct pedit_parser { > > > (na_vlan_priority) =3D > > > conf.of_set_vlan_pcp->vlan_pcp; > > > } > > > + assert(dev_flow->tcf.nlsize >=3D nlh->nlmsg_len); > > > + break; > > > + case RTE_FLOW_ACTION_TYPE_VXLAN_DECAP: > > > + assert(decap.vxlan); > > > + assert(dev_flow->tcf.tunnel); > > > + dev_flow->tcf.tunnel->ifindex_ptr > > > + =3D (unsigned int *)&tcm->tcm_ifindex; > > > + na_act_index =3D > > > + mnl_attr_nest_start(nlh, > > na_act_index_cur++); > > > + assert(na_act_index); > > > + mnl_attr_put_strz(nlh, TCA_ACT_KIND, > > "tunnel_key"); > > > + na_act =3D mnl_attr_nest_start(nlh, > > TCA_ACT_OPTIONS); > > > + assert(na_act); > > > + mnl_attr_put(nlh, TCA_TUNNEL_KEY_PARMS, > > > + sizeof(struct tc_tunnel_key), > > > + &(struct tc_tunnel_key){ > > > + .action =3D TC_ACT_PIPE, > > > + .t_action =3D > > TCA_TUNNEL_KEY_ACT_RELEASE, > > > + }); > > > + mnl_attr_nest_end(nlh, na_act); > > > + mnl_attr_nest_end(nlh, na_act_index); > > > + assert(dev_flow->tcf.nlsize >=3D nlh->nlmsg_len); > > > + break; > > > + case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP: > > > + assert(encap.vxlan); > > > + na_act_index =3D > > > + mnl_attr_nest_start(nlh, > > na_act_index_cur++); > > > + assert(na_act_index); > > > + mnl_attr_put_strz(nlh, TCA_ACT_KIND, > > "tunnel_key"); > > > + na_act =3D mnl_attr_nest_start(nlh, > > TCA_ACT_OPTIONS); > > > + assert(na_act); > > > + mnl_attr_put(nlh, TCA_TUNNEL_KEY_PARMS, > > > + sizeof(struct tc_tunnel_key), > > > + &(struct tc_tunnel_key){ > > > + .action =3D TC_ACT_PIPE, > > > + .t_action =3D > > TCA_TUNNEL_KEY_ACT_SET, > > > + }); > > > + if (encap.vxlan->mask & > > MLX5_FLOW_TCF_ENCAP_UDP_DST) > > > + mnl_attr_put_u16(nlh, > > > + TCA_TUNNEL_KEY_ENC_DST_PORT, > > > + encap.vxlan->udp.dst); > > > + if (encap.vxlan->mask & > > MLX5_FLOW_TCF_ENCAP_IPV4_SRC) > > > + mnl_attr_put_u32(nlh, > > > + TCA_TUNNEL_KEY_ENC_IPV4_SRC, > > > + encap.vxlan->ipv4.src); > > > + if (encap.vxlan->mask & > > MLX5_FLOW_TCF_ENCAP_IPV4_DST) > > > + mnl_attr_put_u32(nlh, > > > + TCA_TUNNEL_KEY_ENC_IPV4_DST, > > > + encap.vxlan->ipv4.dst); > > > + if (encap.vxlan->mask & > > MLX5_FLOW_TCF_ENCAP_IPV6_SRC) > > > + mnl_attr_put(nlh, > > > + TCA_TUNNEL_KEY_ENC_IPV6_SRC, > > > + sizeof(encap.vxlan->ipv6.src), > > > + &encap.vxlan->ipv6.src); > > > + if (encap.vxlan->mask & > > MLX5_FLOW_TCF_ENCAP_IPV6_DST) > > > + mnl_attr_put(nlh, > > > + TCA_TUNNEL_KEY_ENC_IPV6_DST, > > > + sizeof(encap.vxlan->ipv6.dst), > > > + &encap.vxlan->ipv6.dst); > > > + if (encap.vxlan->mask & > > MLX5_FLOW_TCF_ENCAP_VXLAN_VNI) > > > + mnl_attr_put_u32(nlh, > > > + TCA_TUNNEL_KEY_ENC_KEY_ID, > > > + vxlan_vni_as_be32 > > > + (encap.vxlan->vxlan.vni)); > > > +#ifdef TCA_TUNNEL_KEY_NO_CSUM > > > + mnl_attr_put_u8(nlh, TCA_TUNNEL_KEY_NO_CSUM, > > 0); #endif > >=20 > > TCA_TUNNEL_KEY_NO_CSUM is anyway defined like others, then why do > > you treat it differently with #ifdef/#endif? >=20 > As it was found it is not defined on old kernels, on some our CI machines > compilation errors occurred. In your first patch, TCA_TUNNEL_KEY_NO_CSUM is defined if there isn't HAVE_TC_ACT_TUNNEL_KEY. Actually I'm wondering why it is different from HAVE_TCA_TUNNEL_KEY_ENC_DST_PORT. It looks like the following is needed - HAVE_TCA_TUNNEL_KEY_NO_CSUM ?? #ifdef HAVE_TC_ACT_TUNNEL_KEY #include #ifndef HAVE_TCA_TUNNEL_KEY_ENC_DST_PORT #define TCA_TUNNEL_KEY_ENC_DST_PORT 9 #endif #ifndef HAVE_TCA_TUNNEL_KEY_NO_CSUM #define TCA_TUNNEL_KEY_NO_CSUM 10 #endif #else /* HAVE_TC_ACT_TUNNEL_KEY */ Thanks, Yongseok