From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <yskoh@mellanox.com>
Received: from EUR02-HE1-obe.outbound.protection.outlook.com
 (mail-eopbgr10075.outbound.protection.outlook.com [40.107.1.75])
 by dpdk.org (Postfix) with ESMTP id A13AA5F16
 for <dev@dpdk.org>; Tue,  9 Oct 2018 00:08:34 +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=cDhr8xCYL42N5TmzOwwonzbHVXQ6mwcUqbtKQqN6LCM=;
 b=jxRzO9CaW1U1Z2OYiBhks4r35jKzEkCI4ghX2wC/yUhwDUmBpKIgqlh7W3K9hNyVUTehrQ0lSDMMEuftKJsg7YmF8QCrGQKkWkNAHzzpIyol3iDz/Bw2spq1iQgqTjSANUmTFuoKmSA4yeAM108Hg3SbHZjmhIY8pWMfmwDNhA8=
Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by
 DB3PR0502MB3963.eurprd05.prod.outlook.com (52.134.72.22) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.1207.23; Mon, 8 Oct 2018 22:08:32 +0000
Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com
 ([fe80::1cb0:661b:ecab:6045]) by DB3PR0502MB3980.eurprd05.prod.outlook.com
 ([fe80::1cb0:661b:ecab:6045%2]) with mapi id 15.20.1207.024; Mon, 8 Oct 2018
 22:08:32 +0000
From: Yongseok Koh <yskoh@mellanox.com>
To: Jack Min <jackmin@mellanox.com>
CC: Shahaf Shuler <shahafs@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [PATCH] net/mlx5: eswitch-IP address UDP/TCP port rewrite
Thread-Index: AQHUVMYzsnQsXgDklk+QshXlrRt6gqUF4ASAgAKSugCAAfZJgIAK37KAgAC0loA=
Date: Mon, 8 Oct 2018 22:08:32 +0000
Message-ID: <20181008220822.GC9031@mtidpdk.mti.labs.mlnx>
References: <20180925115107.12242-1-jackmin@mellanox.com>
 <20180928230318.GA90324@minint-98vp2qg>
 <20180930072104.f7o5c6yazgznivzd@MTBC-JACKMIN.mtl.com>
 <20181001201752.GA21384@yongseok-MBP.local>
 <20181008112203.kxk7bk5jl4rega6h@MTBC-JACKMIN.mtl.com>
In-Reply-To: <20181008112203.kxk7bk5jl4rega6h@MTBC-JACKMIN.mtl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: CY4PR19CA0031.namprd19.prod.outlook.com
 (2603:10b6:903:103::17) 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; DB3PR0502MB3963;
 6:0uda5tP/DuQLzBV3AfkY96hRFVrYgnIv/J5rt6GrUnDLtOLgveAWd7VAtZ9tlKUHxn26OA+a0zmvhUCEJaF0I1uJO6oyScwObSx4r1EImxGs0xQvvkEGcNLZp2Fp16He3tpokceFlpSnZ0ryz2e/oN5XOUBNPJEpVamjxL1uSiVEouEMPhq+SfpY2BvkbvJM4E8RSaqDQ+L77q9f/+7l/QPEO0d9LF3Mjn/mgJydHSzZDfhntUGGmCgpyCtAVb8z1cgm0LftiddZjJxAQ2yrx9IqLPRELI4Q30nns6IAHLfUooCFGgCXNJLUK/ZUVY/wG1WkIt0Uv4UvcEAeCuRKMBqjS7wr2+L2aZIgtHsr0cZ+z6h6Wln5SMe3dkL9cA9fYAk9a7Aa41VF44+BOyS4du0CYgZPzGGDQifI+ayu55fgO1x82VISkhAF9lCbYLeUKJJoooggG3GvxPm9FJEw/g==;
 5:tkTlOUSiPC8dJ9nPWp8Y0XiDFnUn9iq+3BS2w7dacgousAQ0yRhhIPrlBV1Nf+kqVbx8u/jFmD1h1s/ZgOZYgzMNllhhxti9ks38fpwsQU7FbdzQCasYfUsA2PShusDIU+AZ+DUr2DZnrY7nUShs6dD/tHt8qR3XJi1vg/1kSGg=;
 7:j7jRHRgkfybJenezo7c6CRDKmoqHW2ymFHVEVfcbdYNWntUH51DpJ6rW6r2QYdWrujGP/AlarfW3mZ4z7tGAMREkyE2M9vb5Sy8UwSSSuH7/AnhW9m2BP6q8e7smhgK4gSM2mf9gIqnmKZbRWf002ME7GV40xeWBRsYFmKe3YDTBjO0kFIWoZvtvVNlL2AhwrBNHzgigcmOP8/9PHEp+deAJxpuCIqDgR4lxISDG0gb3DNnrkgx7a/TyuJZzqFix
x-ms-office365-filtering-correlation-id: e2226be7-45e5-47d5-3461-08d62d6a9559
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:DB3PR0502MB3963; 
x-ms-traffictypediagnostic: DB3PR0502MB3963:
x-microsoft-antispam-prvs: <DB3PR0502MB3963BC30452A95A1FD2427DAC3E60@DB3PR0502MB3963.eurprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(163750095850)(17755550239193);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
 RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(201708071742011)(7699051);
 SRVR:DB3PR0502MB3963; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0502MB3963; 
x-forefront-prvs: 081904387B
x-forefront-antispam-report: SFV:NSPM;
 SFS:(10009020)(136003)(396003)(376002)(346002)(39860400002)(366004)(189003)(199004)(53546011)(386003)(6506007)(316002)(76176011)(6436002)(25786009)(6246003)(106356001)(6486002)(105586002)(5250100002)(7736002)(229853002)(33896004)(186003)(4326008)(6862004)(71190400001)(71200400001)(1076002)(93886005)(54906003)(26005)(3846002)(6116002)(97736004)(52116002)(99286004)(33656002)(102836004)(2906002)(5660300001)(305945005)(81166006)(4744004)(8676002)(81156014)(66066001)(8936002)(6636002)(256004)(14444005)(2900100001)(6306002)(6512007)(86362001)(9686003)(11346002)(53946003)(446003)(966005)(486006)(476003)(68736007)(14454004)(478600001)(53936002)(559001)(579004);
 DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB3963;
 H:DB3PR0502MB3980.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en;
 PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: mellanox.com does not designate
 permitted sender hosts)
x-microsoft-antispam-message-info: ziXExoU8YoUZu3Vke0Uj1OZn5PJIZD9zBj9ti+YzMbSh+u9nC7l1zBRyHKy9C2yRM+GDFohnbl95KiNRHtrghnDgcIjd1m6fgH52NHrz7Dp7kNCAs0Q+Dtfr2chJ2AmugTO1IRD+RgDEc4FhudlY0Fj3JDci5BQRa15BFDg52rWZ0piRgYkDFvQZxhKqPIyaqYqmGsw8sra0XfeMobd2J7tusHlgslMHKtBgJ+f7hgp2+C/qoubdMRPvhCOS+ja07goK3697AFU6rwp0ayrq9moac9eqGP1QyncICjfXjgrEfLclS/ptEdfmN8hKHIH7izpSnO44AJN6dItN1sZxkM39W421Yinl/IQPmN2xvW0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <315EB6696C11114C9477EBC4DEAEA967@eurprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Mellanox.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e2226be7-45e5-47d5-3461-08d62d6a9559
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2018 22:08:32.1473 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0502MB3963
Subject: Re: [dpdk-dev] [PATCH] net/mlx5: eswitch-IP address UDP/TCP port
	rewrite
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
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>
X-List-Received-Date: Mon, 08 Oct 2018 22:08:35 -0000

On Mon, Oct 08, 2018 at 07:22:03PM +0800, Xiaoyu Min wrote:
> On 18-10-02 04:19:00, Yongseok Koh wrote:
> > On Sun, Sep 30, 2018 at 03:21:04PM +0800, Xiaoyu Min wrote:
> > > On 18-09-29 07:03:33, Yongseok Koh wrote:
> > > > On Tue, Sep 25, 2018 at 07:51:06PM +0800, Xiaoyu Min wrote:
> > > > > Offload the following rte_flow actions by inserting accordingly
> > > > > E-Switch rules via TC Flower driver
> > > > >=20
> > > > >  - RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC
> > > > >  - RTE_FLOW_ACTION_TYPE_SET_IPV4_DST
> > > > >  - RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC
> > > > >  - RTE_FLOW_ACTION_TYPE_SET_IPV6_DST
> > > > >  - RTE_FLOW_ACTION_TYPE_SET_TP_SRC
> > > > >  - RTE_FLOW_ACTION_TYPE_SET_TP_DST
> > > >=20
> > > > Can you put an example command of testpmd for the reference?
> > > >=20
> > > Sure, I'll add.
> > >=20
> > > > > Signed-off-by: Xiaoyu Min <jackmin@mellanox.com>
> > > > > ---
> > > > > This patch bases on Rahul Lakkireddy's patchs[1][2] and
> > > > > Yongseok Koh's patchset [3]
> > > > >=20
> > > > > [1] https://patches.dpdk.org/patch/45191/
> > > > > [2] https://patches.dpdk.org/patch/45192/
> > > > > [3] https://patches.dpdk.org/project/dpdk/list/?series=3D1474
> > > > >=20
> > > > >=20
> > > > >  drivers/net/mlx5/Makefile        |   5 +
> > > > >  drivers/net/mlx5/meson.build     |   2 +
> > > > >  drivers/net/mlx5/mlx5_flow.h     |   6 +
> > > > >  drivers/net/mlx5/mlx5_flow_tcf.c | 356 +++++++++++++++++++++++++=
++++++
> > > > >  4 files changed, 369 insertions(+)
> > > > >=20
> > > > > diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefil=
e
> > > > > index ca1de9f21..49b95e78e 100644
> > > > > --- a/drivers/net/mlx5/Makefile
> > > > > +++ b/drivers/net/mlx5/Makefile
> > > > > @@ -346,6 +346,11 @@ mlx5_autoconf.h.new: $(RTE_SDK)/buildtools/a=
uto-config-h.sh
> > > > >  		linux/tc_act/tc_vlan.h \
> > > > >  		enum TCA_VLAN_PUSH_VLAN_PRIORITY \
> > > > >  		$(AUTOCONF_OUTPUT)
> > > > > +	$Q sh -- '$<' '$@' \
> > > > > +		HAVE_TC_ACT_PEDIT \
> > > > > +		linux/tc_act/tc_pedit.h \
> > > > > +		enum TCA_PEDIT_KEY_EX_HDR_TYPE_UDP \
> > > > > +		$(AUTOCONF_OUTPUT)
> > > > >  	$Q sh -- '$<' '$@' \
> > > > >  		HAVE_SUPPORTED_40000baseKR4_Full \
> > > > >  		/usr/include/linux/ethtool.h \
> > > > > diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meso=
n.build
> > > > > index fd93ac162..ef6a85101 100644
> > > > > --- a/drivers/net/mlx5/meson.build
> > > > > +++ b/drivers/net/mlx5/meson.build
> > > > > @@ -182,6 +182,8 @@ if build
> > > > >  		'TCA_FLOWER_KEY_VLAN_ETH_TYPE' ],
> > > > >  		[ 'HAVE_TC_ACT_VLAN', 'linux/tc_act/tc_vlan.h',
> > > > >  		'TCA_VLAN_PUSH_VLAN_PRIORITY' ],
> > > > > +		[ 'HAVE_TC_ACT_PEDIT', 'linux/tc_act/tc_pedit.h',
> > > > > +		'TCA_PEDIT_KEY_EX_HDR_TYPE_UDP' ],
> > > > >  		[ 'HAVE_RDMA_NL_NLDEV', 'rdma/rdma_netlink.h',
> > > > >  		'RDMA_NL_NLDEV' ],
> > > > >  		[ 'HAVE_RDMA_NLDEV_CMD_GET', 'rdma/rdma_netlink.h',
> > > > > diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5=
_flow.h
> > > > > index 10d700a7f..be182a643 100644
> > > > > --- a/drivers/net/mlx5/mlx5_flow.h
> > > > > +++ b/drivers/net/mlx5/mlx5_flow.h
> > > > > @@ -87,6 +87,12 @@
> > > > >  #define MLX5_ACTION_OF_PUSH_VLAN (1u << 8)
> > > > >  #define MLX5_ACTION_OF_SET_VLAN_VID (1u << 9)
> > > > >  #define MLX5_ACTION_OF_SET_VLAN_PCP (1u << 10)
> > > > > +#define MLX5_ACTION_SET_IPV4_SRC (1u << 11)
> > > > > +#define MLX5_ACTION_SET_IPV4_DST (1u << 12)
> > > > > +#define MLX5_ACTION_SET_IPV6_SRC (1u << 13)
> > > > > +#define MLX5_ACTION_SET_IPV6_DST (1u << 14)
> > > > > +#define MLX5_ACTION_SET_TP_SRC (1u << 15)
> > > > > +#define MLX5_ACTION_SET_TP_DST (1u << 16)
> > > > > =20
> > > > >  /* possible L3 layers protocols filtering. */
> > > > >  #define MLX5_IP_PROTOCOL_TCP 6
> > > > > diff --git a/drivers/net/mlx5/mlx5_flow_tcf.c b/drivers/net/mlx5/=
mlx5_flow_tcf.c
> > > > > index 14376188e..85c92f369 100644
> > > > > --- a/drivers/net/mlx5/mlx5_flow_tcf.c
> > > > > +++ b/drivers/net/mlx5/mlx5_flow_tcf.c
> > > > > @@ -53,6 +53,62 @@ struct tc_vlan {
> > > > > =20
> > > > >  #endif /* HAVE_TC_ACT_VLAN */
> > > > > =20
> > > > > +#ifdef HAVE_TC_ACT_PEDIT
> > > > > +
> > > > > +#include <linux/tc_act/tc_pedit.h>
> > > > > +
> > > > > +#else /* HAVE_TC_ACT_VLAN */
> > > > > +enum {
> > > > > +	TCA_PEDIT_UNSPEC,
> > > > > +	TCA_PEDIT_TM,
> > > > > +	TCA_PEDIT_PARMS,
> > > > > +	TCA_PEDIT_PAD,
> > > > > +	TCA_PEDIT_PARMS_EX,
> > > > > +	TCA_PEDIT_KEYS_EX,
> > > > > +	TCA_PEDIT_KEY_EX,
> > > > > +	__TCA_PEDIT_MAX
> > > > > +};
> > > > > +
> > > > > +enum {
> > > > > +	TCA_PEDIT_KEY_EX_HTYPE =3D 1,
> > > > > +	TCA_PEDIT_KEY_EX_CMD =3D 2,
> > > > > +	__TCA_PEDIT_KEY_EX_MAX
> > > > > +};
> > > > > +
> > > > > +enum pedit_header_type {
> > > > > +	TCA_PEDIT_KEY_EX_HDR_TYPE_NETWORK =3D 0,
> > > > > +	TCA_PEDIT_KEY_EX_HDR_TYPE_ETH =3D 1,
> > > > > +	TCA_PEDIT_KEY_EX_HDR_TYPE_IP4 =3D 2,
> > > > > +	TCA_PEDIT_KEY_EX_HDR_TYPE_IP6 =3D 3,
> > > > > +	TCA_PEDIT_KEY_EX_HDR_TYPE_TCP =3D 4,
> > > > > +	TCA_PEDIT_KEY_EX_HDR_TYPE_UDP =3D 5,
> > > > > +	__PEDIT_HDR_TYPE_MAX,
> > > > > +};
> > > > > +
> > > > > +enum pedit_cmd {
> > > > > +	TCA_PEDIT_KEY_EX_CMD_SET =3D 0,
> > > > > +	TCA_PEDIT_KEY_EX_CMD_ADD =3D 1,
> > > > > +	__PEDIT_CMD_MAX,
> > > > > +};
> > > > > +
> > > > > +struct tc_pedit_key {
> > > > > +	__u32           mask;  /* AND */
> > > > > +	__u32           val;   /*XOR */
> > > > > +	__u32           off;  /*offset */
> > > > > +	__u32           at;
> > > > > +	__u32           offmask;
> > > > > +	__u32           shift;
> > > > > +};
> > > > > +
> > > > > +struct tc_pedit_sel {
> > > > > +	tc_gen;
> > > > > +	unsigned char           nkeys;
> > > > > +	unsigned char           flags;
> > > > > +	struct tc_pedit_key     keys[0];
> > > > > +};
> > > > > +
> > > > > +#endif /* HAVE_TC_ACT_VLAN */
> > > > > +
> > > > >  /* Normally found in linux/netlink.h. */
> > > > >  #ifndef NETLINK_CAP_ACK
> > > > >  #define NETLINK_CAP_ACK 10
> > > > > @@ -153,6 +209,14 @@ struct tc_vlan {
> > > > >  #define IPV6_ADDR_LEN 16
> > > > >  #endif
> > > > > =20
> > > > > +#ifndef IPV4_ADDR_LEN
> > > > > +#define IPV4_ADDR_LEN 4
> > > > > +#endif
> > > > > +
> > > > > +#ifndef TP_PORT_LEN
> > > > > +#define TP_PORT_LEN 2 /* Transport Port (UDP/TCP) Length */
> > > > > +#endif
> > > > > +
> > > > >  /** Empty masks for known item types. */
> > > > >  static const union {
> > > > >  	struct rte_flow_item_port_id port_id;
> > > > > @@ -227,6 +291,220 @@ struct flow_tcf_ptoi {
> > > > > =20
> > > > >  #define MLX5_TCF_FATE_ACTIONS (MLX5_ACTION_DROP | MLX5_ACTION_PO=
RT_ID)
> > > > > =20
> > > > > +#define IS_MODIFY_ACTION(act_) ({typeof(act_) act =3D (act_); \
> > > > > +		((act) =3D=3D RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC || \
> > > > > +		(act) =3D=3D RTE_FLOW_ACTION_TYPE_SET_IPV4_DST  || \
> > > > > +		(act) =3D=3D RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC  || \
> > > > > +		(act) =3D=3D RTE_FLOW_ACTION_TYPE_SET_IPV6_DST  || \
> > > > > +		(act) =3D=3D RTE_FLOW_ACTION_TYPE_SET_TP_SRC    || \
> > > > > +		(act) =3D=3D RTE_FLOW_ACTION_TYPE_SET_TP_DST) ?    \
> > > > > +		1 : 0; })
> > > >=20
> > > > The reason why you need this complex multi-conditional macro is tha=
t
> > > > RTE_FLOW_ACTION_TYPE_* isn't a bitmask. But, as this actions will b=
e converted
> > > > to MLX5_ACTION_* which is a bitmask, you can use that instead. Then=
, this
> > > > would be enough to be:
> > > >=20
> > > > #define MLX5_TCF_SET_ACTIONS \
> > > > 	(MLX5_ACTION_SET_IPV4_SRC | ...)
> > > >=20
> > > > And in the flow_tcf_validate() below,
> > > > 	if (action_flags & MLX5_TCF_SET_ACTIONS) {
> > > > 		...
> > > > 	}
> > > >=20
> > > Well, I did consider using bitmask but action_flags is an _accumulate=
d_ variable,
> > > records all the actions parsed so far.
> > > But, here, I need to know what is the _current_ action and whether it=
 belongs to modify
> > > actions. If using bitmask, Looks like a new variable (i.e current_act=
ion) needed (?)
> > >=20
> > > case RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC:
> > >     current_action =3D MLX5_ACTION_SET_IPV4_SRC;
> > >     .....
> > >=20
> > > if (current_action & MLX5_TCF_SET_ACTIONS) ...
> > >  ...
> > >=20
> > > action_flags |=3D current_action;
> > >=20
> > > I feel more code change needed or you think it's worth?
> >=20
> > Understood what you meant.
> > Please see my comment below in the flow_tcf_validate().
> >=20
> > > > And please note that I'm going to rename MLX5_ACTION_* to MLX5_FLOW=
_ACTION_*.
> > > > Please refer to "net/mlx5: rename flow macros" in PR #885. You migh=
t need to
> > > > rebase it again.
> > > >=20
> > > Sure, I'll rebase on it
> > >=20
> > > > > +#define MAX_PEDIT_KEYS (128)
> > > > > +#define SZ_PEDIT_KEY_VAL (4)
> > > > > +
> > > > > +struct pedit_key_ex {
> > > > > +	enum pedit_header_type htype;
> > > > > +	enum pedit_cmd cmd;
> > > > > +};
> > > > > +
> > > > > +struct pedit_parser {
> > > > > +	struct tc_pedit_sel sel;
> > > > > +	struct tc_pedit_key keys[MAX_PEDIT_KEYS];
> > > > > +	struct pedit_key_ex keys_ex[MAX_PEDIT_KEYS];
> > > > > +};
> > > > > +
> > > > > +static int
> > > > > +flow_tcf_calc_pedit_keys(const uint64_t size)
> > > >=20
> > > > Please add documentation by comment for every funcs you add.
> > > > Refer to the other existing ones for formality.
> > > >=20
> > > Sure!
> > > > > +{
> > > > > +	int keys =3D (size / SZ_PEDIT_KEY_VAL) +
> > > > > +		((size % SZ_PEDIT_KEY_VAL) ? 1 : 0);
> > > >=20
> > > > Indentation.
> > > >=20
> > > Will fix it
> > > > > +	return keys;
> > > > > +}
> > > > > +
> > > > > +static void
> > > > > +flow_tcf_pedit_key_set_tp_port(const struct rte_flow_action *act=
ions,
> > > > > +				struct pedit_parser *p_parser,
> > > > > +				uint64_t item_flags)
> > > > > +{
> > > > > +	int idx =3D p_parser->sel.nkeys;
> > > > > +
> > > > > +	if (item_flags & MLX5_FLOW_LAYER_OUTER_L4_UDP)
> > > > > +		p_parser->keys_ex[idx].htype =3D TCA_PEDIT_KEY_EX_HDR_TYPE_UDP=
;
> > > > > +	if (item_flags & MLX5_FLOW_LAYER_OUTER_L4_TCP)
> > > > > +		p_parser->keys_ex[idx].htype =3D TCA_PEDIT_KEY_EX_HDR_TYPE_TCP=
;
> > > > > +	p_parser->keys_ex[idx].cmd =3D TCA_PEDIT_KEY_EX_CMD_SET;
> > > > > +	p_parser->keys[idx].off =3D
> > > > > +		actions->type =3D=3D RTE_FLOW_ACTION_TYPE_SET_TP_DST ? 2 : 0;
> > > >=20
> > > > 	assert(offsetof(struct tcp_hdr, src_port) =3D=3D
> > > > 	       offsetof(struct udp_hdr, src_port));
> > > > 	assert(offsetof(struct tcp_hdr, dst_port) =3D=3D
> > > > 	       offsetof(struct udp_hdr, dst_port));
> > > > 	p_parser->keys[idx].off =3D
> > > > 		actions->type =3D=3D RTE_FLOW_ACTION_TYPE_SET_TP_SRC ?
> > > > 		offsetof(struct tcp_hdr, src_port) :
> > > > 		offsetof(struct tcp_hdr, dst_port);
> > > >=20
> > > > assert() is just to be informative.
> > > > And how about src first like others below?
> > > >=20
> > > Yes, I will update above.
> > >=20
> > > > > +	p_parser->keys[idx].mask =3D 0xFFFF0000;
> > > > > +	p_parser->keys[idx].val =3D ((const struct rte_flow_action_set_=
tp *)
> > > > > +			actions->conf)->port;
> > > >=20
> > > > Assigning 2B to 4B big-endian stroage? Doesn't look consistent with=
 the mask
> > > > above - 0xffff0000.
> > > >=20
> > > So it should be as following ?
> > > p_parser->keys[idx].val =3D (__u32)((const struct rte_flow_action_set=
_tp *))
> > >                 actions->conf)->port;
> >=20
> > You can figure it out by actual tests but I think the following would b=
e right.
> > 	p_parser->keys[idx].val =3D
> > 		rte_cpu_to_be_32(((const struct rte_flow_action_set_tp *)
> > 				  actions->conf)->port);
> >=20
> > Please verify it by testing anyway.
> >=20
> No, it doesn't work correctly if it's converted to BE.
> As my understanding the Netlink message should be expressed in host-byte =
order (?)

As far as I know rte_flow takes network-byte order for args and tcf na msg =
takes
host-byte order. Please refer to the "override_na_vlan_id:" in mlx5_flow_tc=
f.c,
rte_be_to_cpu_16() is used there.  I'm still confusing why the mask is
0xffff0000 above. Please make sure your code works correctly by multiple te=
st
cases and hopefully I can hear clear explanation what is right and why.

> > > > > +	p_parser->sel.nkeys =3D (++idx);
> > > > > +}
> > > > > +
> > > > > +static void
> > > > > +flow_tcf_pedit_key_set_ipv6_addr(const struct rte_flow_action *a=
ctions,
> > > > > +				 struct pedit_parser *p_parser)
> > > > > +{
> > > > > +	int idx =3D p_parser->sel.nkeys;
> > > > > +	int keys =3D flow_tcf_calc_pedit_keys(IPV6_ADDR_LEN);
> > > > > +	int off_base =3D
> > > > > +		actions->type =3D=3D RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC ? 8 : 2=
4;
> > > >=20
> > > > offsetof(struct ipv6_hdr, src_addr) :
> > > > offsetof(struct ipv6_hdr, dst_addr);
> > > >=20
> > > Got it!
> > > > > +	const struct rte_flow_action_set_ipv6 *conf =3D
> > > > > +		(const struct rte_flow_action_set_ipv6 *)actions->conf;
> > > > > +
> > > > > +	for (int i =3D 0; i < keys; i++, idx++) {
> > > > > +		p_parser->keys_ex[idx].htype =3D TCA_PEDIT_KEY_EX_HDR_TYPE_IP6=
;
> > > > > +		p_parser->keys_ex[idx].cmd =3D TCA_PEDIT_KEY_EX_CMD_SET;
> > > > > +		p_parser->keys[idx].off =3D off_base + i * SZ_PEDIT_KEY_VAL;
> > > > > +		p_parser->keys[idx].mask =3D ~UINT32_MAX;
> > > > > +		memcpy(&p_parser->keys[idx].val,
> > > > > +			conf->ipv6_addr + i *  SZ_PEDIT_KEY_VAL,
> > > > > +			SZ_PEDIT_KEY_VAL);
> > > > > +	}
> > > > > +	p_parser->sel.nkeys +=3D keys;
> > > > > +}
> > > > > +
> > > > > +static void
> > > > > +flow_tcf_pedit_key_set_ipv4_addr(const struct rte_flow_action *a=
ctions,
> > > >=20
> > > > How about getting rte_flow_action_set_ipv4 instead of rte_flow_acti=
on?
> > > > Same comment for ipv6 and tp_port.
> > > >=20
> > > What's the benefit by using rte_flow_action_set_ipv4 and how I know i=
t's
> > > for src or dst address ?
> >=20
> > Just to make the function neat but I overlooked that you still need
> > actions->type. Please disregard my previous comment.
> >=20
> OK~
> > > > > +				 struct pedit_parser *p_parser)
> > > > > +{
> > > > > +	int idx =3D p_parser->sel.nkeys;
> > > > > +
> > > > > +	p_parser->keys_ex[idx].htype =3D TCA_PEDIT_KEY_EX_HDR_TYPE_IP4;
> > > > > +	p_parser->keys_ex[idx].cmd =3D TCA_PEDIT_KEY_EX_CMD_SET;
> > > > > +	p_parser->keys[idx].off =3D
> > > > > +		(actions->type =3D=3D RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC ? 12 :=
 16);
> > > >=20
> > > > offsetof(struct ipv4_hdr, src_addr) :
> > > > offsetof(struct ipv4_hdr, dst_addr);
> > > >=20
> > > Got it!
> > > > > +	p_parser->keys[idx].mask =3D ~UINT32_MAX;
> > > > > +	p_parser->keys[idx].val =3D
> > > > > +		((const struct rte_flow_action_set_ipv4 *)
> > > > > +		 actions->conf)->ipv4_addr;
> > > > > +	p_parser->sel.nkeys =3D (++idx);
> > > > > +}
> > > > > +
> > > > > +static int
> > > > > +flow_tcf_create_pedit_mnl_msg(struct nlmsghdr *nl,
> > > > > +			      const struct rte_flow_action **actions,
> > > > > +			      uint64_t item_flags)
> > > > > +{
> > > > > +	struct pedit_parser p_parser;
> > > > > +
> > > > > +	memset(&p_parser, 0, sizeof(p_parser));
> > > > > +	mnl_attr_put_strz(nl, TCA_ACT_KIND, "pedit");
> > > > > +	struct nlattr *na_act_options =3D mnl_attr_nest_start(nl,
> > > > > +							    TCA_ACT_OPTIONS);
> > > > > +	/* all modify header actions should be in one tc-pedit action *=
/
> > > > > +	for (; (*actions)->type !=3D RTE_FLOW_ACTION_TYPE_END; (*action=
s)++) {
> > > >=20
> > > > It seems that you want to aggregate all the pedit actions and form =
a single
> > > > na attr. But what if rte_flow_action_set_* are not contiguous? E.g.
> > > >=20
> > > > flow create ... actions set1 / set2 / port_id / set3 / end
> > > >=20
> > > > Then, it would have two pedit na attrs. Is that okay?
> > > > Or, need to think about another way?
> > > >=20
> > > > Same will happen in flow_tcf_get_pedit_actions_size().
> > > >=20
> > > It's OK if we have more than one pedit na attrs.
> > > _BUT_ only last pedit take effect based on my experiment
> >=20
> > Then, shouldn't we give some warning to user in validation? So that use=
r can
> > have right expectation and reorder the actions as their intention like:
> > 	flow create ... actions set1 / set2 / set3 / port_id / end
> >=20
> > Otherwise set1 and set2 will be lost according to your comment.
> >=20
> I prefer to give error to user in validation because this is simple.

Good.

> > Or, how about making PMD do the right thing. I mean, even if the set ac=
tions are
> > scattered, PMD can collect it and apply in a single na attr?
> >=20
> My feeling is the above approach will be (become) complex. It looks like =
we introduce
> new functionality which re-order all actions, something like rss_expand.=
=20

+1

> > > > > +		switch ((*actions)->type) {
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC:
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV4_DST:
> > > > > +			flow_tcf_pedit_key_set_ipv4_addr(*actions, &p_parser);
> > > > > +			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC:
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV6_DST:
> > > > > +			flow_tcf_pedit_key_set_ipv6_addr(*actions, &p_parser);
> > > > > +			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_TP_SRC:
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_TP_DST:
> > > > > +			flow_tcf_pedit_key_set_tp_port(*actions,
> > > > > +							&p_parser, item_flags);
> > > > > +			break;
> > > > > +		default:
> > > > > +			goto pedit_mnl_msg_done;
> > > > > +		}
> > > > > +	}
> > > > > +pedit_mnl_msg_done:
> > > > > +	p_parser.sel.action =3D TC_ACT_PIPE;
> > > > > +	mnl_attr_put(nl, TCA_PEDIT_PARMS_EX,
> > > > > +			sizeof(p_parser.sel) +
> > > > > +			p_parser.sel.nkeys * sizeof(struct tc_pedit_key),
> > > > > +			&p_parser);
> > > > > +	struct nlattr *na_pedit_keys =3D mnl_attr_nest_start(nl,
> > > > > +					TCA_PEDIT_KEYS_EX | NLA_F_NESTED);
> > > > > +	for (int i =3D 0; i < p_parser.sel.nkeys; i++) {
> > > > > +		struct nlattr *na_pedit_key =3D mnl_attr_nest_start(nl,
> > > > > +					TCA_PEDIT_KEY_EX | NLA_F_NESTED);
> > > > > +		mnl_attr_put_u16(nl, TCA_PEDIT_KEY_EX_HTYPE,
> > > > > +				 p_parser.keys_ex[i].htype);
> > > > > +		mnl_attr_put_u16(nl, TCA_PEDIT_KEY_EX_CMD,
> > > > > +				 p_parser.keys_ex[i].cmd);
> > > > > +		mnl_attr_nest_end(nl, na_pedit_key);
> > > > > +	}
> > > > > +	mnl_attr_nest_end(nl, na_pedit_keys);
> > > > > +	mnl_attr_nest_end(nl, na_act_options);
> > > > > +	(*actions)--;
> > > > > +	return 0;
> > > > > +}
> > > > > +
> > > > > +/**
> > > > > + * Calculate max memory size of one TC-pedit actions.
> > > > > + * One TC-pedit action can contain set of keys each defining
> > > > > + * a rewrite element (rte_flow action)
> > > > > + *
> > > > > + * @param[in] actions
> > > > > + *   actions specification.
> > > > > + * @param[inout] action_flags
> > > > > + *   actions flags
> > > > > + * @param[inout] size
> > > > > + *   accumulated size
> > > > > + * @return
> > > > > + *   Max memory size of one TC-pedit action
> > > > > + */
> > > > > +static int
> > > > > +flow_tcf_get_pedit_actions_size(const struct rte_flow_action **a=
ctions,
> > > > > +				uint64_t *action_flags)
> > > > > +{
> > > > > +	int pedit_size =3D 0;
> > > > > +	int keys =3D 0;
> > > > > +	uint64_t flags =3D 0;
> > > > > +
> > > > > +	pedit_size +=3D SZ_NLATTR_NEST + /* na_act_index. */
> > > > > +		      SZ_NLATTR_STRZ_OF("pedit") +
> > > > > +		      SZ_NLATTR_NEST; /* TCA_ACT_OPTIONS. */
> > > > > +	for (; (*actions)->type !=3D RTE_FLOW_ACTION_TYPE_END; (*action=
s)++) {
> > > > > +		switch ((*actions)->type) {
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC:
> > > > > +			keys +=3D flow_tcf_calc_pedit_keys(IPV4_ADDR_LEN);
> > > > > +			flags |=3D MLX5_ACTION_SET_IPV4_SRC;
> > > > > +			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV4_DST:
> > > > > +			keys +=3D flow_tcf_calc_pedit_keys(IPV4_ADDR_LEN);
> > > > > +			flags |=3D MLX5_ACTION_SET_IPV4_DST;
> > > > > +			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC:
> > > > > +			keys +=3D flow_tcf_calc_pedit_keys(IPV6_ADDR_LEN);
> > > > > +			flags |=3D MLX5_ACTION_SET_IPV6_SRC;
> > > > > +			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV6_DST:
> > > > > +			keys +=3D flow_tcf_calc_pedit_keys(IPV6_ADDR_LEN);
> > > > > +			flags |=3D MLX5_ACTION_SET_IPV6_DST;
> > > > > +			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_TP_SRC:
> > > > > +			/* TCP is as same as UDP */
> > > > > +			keys +=3D flow_tcf_calc_pedit_keys(TP_PORT_LEN);
> > > > > +			flags |=3D MLX5_ACTION_SET_TP_SRC;
> > > > > +			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_TP_DST:
> > > > > +			/* TCP is as same as UDP */
> > > > > +			keys +=3D flow_tcf_calc_pedit_keys(TP_PORT_LEN);
> > > > > +			flags |=3D MLX5_ACTION_SET_TP_DST;
> > > > > +			break;
> > > > > +		default:
> > > > > +			goto get_pedit_action_size_done;
> > > > > +		}
> > > > > +	}
> > > > > +get_pedit_action_size_done:
> > > > > +	/* TCA_PEDIT_PARAMS_EX */
> > > > > +	pedit_size +=3D SZ_NLATTR_DATA_OF(sizeof(struct tc_pedit_sel) +
> > > > > +			keys * sizeof(struct tc_pedit_key));
> > > >=20
> > > > > +	pedit_size +=3D SZ_NLATTR_NEST; /* TCA_PEDIT_KEYS */
> > > > > +	pedit_size +=3D keys *
> > > > > +		/* TCA_PEDIT_KEY_EX + HTYPE + CMD */
> > > > > +		(SZ_NLATTR_NEST + SZ_NLATTR_DATA_OF(2) + SZ_NLATTR_DATA_OF(2))=
;
> > > > > +	(*action_flags) |=3D flags;
> > > > > +	(*actions)--;
> > > > > +	return pedit_size;
> > > > > +}
> > > > > +
> > > > >  /**
> > > > >   * Retrieve mask for pattern item.
> > > > >   *
> > > > > @@ -430,6 +708,8 @@ flow_tcf_validate(struct rte_eth_dev *dev,
> > > > >  			of_set_vlan_vid;
> > > > >  		const struct rte_flow_action_of_set_vlan_pcp *
> > > > >  			of_set_vlan_pcp;
> > > > > +		const struct rte_flow_action_set_ipv4 *set_ipv4;
> > > > > +		const struct rte_flow_action_set_ipv6 *set_ipv6;
> > > > >  	} conf;
> > > > >  	uint32_t item_flags =3D 0;
> > > > >  	uint32_t action_flags =3D 0;
> > > > > @@ -690,12 +970,64 @@ flow_tcf_validate(struct rte_eth_dev *dev,
> > > > >  		case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
> > > > >  			action_flags |=3D MLX5_ACTION_OF_SET_VLAN_PCP;
> > > > >  			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC:
> > > > > +			action_flags |=3D MLX5_ACTION_SET_IPV4_SRC;
> > > > > +			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV4_DST:
> > > > > +			action_flags |=3D MLX5_ACTION_SET_IPV4_DST;
> > > > > +			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC:
> > > > > +			action_flags |=3D MLX5_ACTION_SET_IPV6_SRC;
> > > > > +			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV6_DST:
> > > > > +			action_flags |=3D MLX5_ACTION_SET_IPV6_DST;
> > > > > +			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_TP_SRC:
> > > > > +			action_flags |=3D MLX5_ACTION_SET_TP_SRC;
> > > > > +			break;
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_TP_DST:
> > > > > +			action_flags |=3D MLX5_ACTION_SET_TP_DST;
> > > > > +			break;
> > > > >  		default:
> > > > >  			return rte_flow_error_set(error, ENOTSUP,
> > > > >  						  RTE_FLOW_ERROR_TYPE_ACTION,
> > > > >  						  actions,
> > > > >  						  "action not supported");
> > > > >  		}
> > > > > +		if (IS_MODIFY_ACTION(actions->type)) {
> >=20
> > This would be a redundant 'if' as classification is already done above.=
 So, how
> > about adding a goto label at the end of this code - 'err_no_action_conf=
:', and
> > use goto above.  E.g.,
> >=20
> > 		case RTE_FLOW_ACTION_TYPE_SET_TP_DST:
> > 			action_flags |=3D MLX5_ACTION_SET_TP_DST;
> > 			if (!actions->conf)
> > 				goto err_no_action_conf;
> > 			break;
> >=20
> In some level I do agree with you it's redundant. But things like this ki=
nd of
> redundancy is not avoidable. I mean if we use "goto err_no_action_conf", =
the
> "if (!actions->conf) goto err_no_action_conf" has to be repeated in each =
"case"
> which needs to check conf or you think it's acceptable ?

But in your approach, the redundant check (IS_MODIFY_ACTION) is inside a lo=
op
and it has to be checked even if there's no 'set' action in the action list=
.

> > And if I may, can I ask you to add the same to RTE_FLOW_ACTION_TYPE_POR=
T_ID?
> >=20
> Yes, I will add.
> > > > > +			if (!actions->conf)
> > > > > +				return rte_flow_error_set(error, ENOTSUP,
> > > > > +						RTE_FLOW_ERROR_TYPE_ACTION_CONF,
> > > > > +						actions,
> > > > > +						"action configuration not set");
> > > > > +		}
> > > > > +	}
> > > > > +	if (action_flags &
> > > > > +	   (MLX5_ACTION_SET_IPV4_SRC | MLX5_ACTION_SET_IPV4_DST)) {
> > > > > +		if (!(item_flags & MLX5_FLOW_LAYER_OUTER_L3_IPV4))
> > > > > +			return rte_flow_error_set(error, ENOTSUP,
> > > > > +						  RTE_FLOW_ERROR_TYPE_ACTION,
> > > > > +						  actions,
> > > > > +						  "no ipv4 item found in"
> > > > > +						  " pattern");
> > > > > +	}
> > > > > +	if (action_flags &
> > > > > +	   (MLX5_ACTION_SET_IPV6_SRC | MLX5_ACTION_SET_IPV6_DST)) {
> > > > > +		if (!(item_flags & MLX5_FLOW_LAYER_OUTER_L3_IPV6))
> > > > > +			return rte_flow_error_set(error, ENOTSUP,
> > > > > +				RTE_FLOW_ERROR_TYPE_ACTION,
> > > > > +				actions,
> > > > > +				"no ipv6 item found in pattern");
> > > > > +	}
> > > > > +	if (action_flags & (MLX5_ACTION_SET_TP_SRC | MLX5_ACTION_SET_TP=
_DST)) {
> > > > > +		if (!(item_flags &
> > > > > +		     (MLX5_FLOW_LAYER_OUTER_L4_UDP |
> > > > > +		      MLX5_FLOW_LAYER_OUTER_L4_TCP)))
> > > > > +			return rte_flow_error_set(error, ENOTSUP,
> > > > > +						RTE_FLOW_ERROR_TYPE_ACTION,
> > > > > +						actions,
> > > > > +						"no TCP/UDP item found in"
> > > > > +						" pattern");
> >=20
> > All the errors you added, I think EINVAL would be a better fit?
> >=20
> Yes, EINVAL should be better.
> > > > Isn't this 'set' action compatible with drop action? No point of mo=
difying
> > > > packet which will be dropped, isn't it?
> > > >=20
> > > Yes, you are absolutely right :-)
> >=20
> > I believe you'll add a validation code for that in the next version. :-=
)
> >=20
> Of course ;-)
> > > > >  	}
> > > > >  	return 0;
> > > > >  }
> > > > > @@ -840,6 +1172,15 @@ flow_tcf_get_actions_and_size(const struct =
rte_flow_action actions[],
> > > > >  				SZ_NLATTR_TYPE_OF(uint16_t) + /* VLAN ID. */
> > > > >  				SZ_NLATTR_TYPE_OF(uint8_t); /* VLAN prio. */
> > > > >  			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:
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV6_DST:
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_TP_SRC:
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_TP_DST:
> > > > > +			size +=3D flow_tcf_get_pedit_actions_size(&actions,
> > > > > +								&flags);
> > > > > +			break;
> > > > >  		default:
> > > > >  			DRV_LOG(WARNING,
> > > > >  				"unsupported action %p type %d,"
> > > > > @@ -998,6 +1339,7 @@ flow_tcf_translate(struct rte_eth_dev *dev, =
struct mlx5_flow *dev_flow,
> > > > >  	struct nlattr *na_flower_act;
> > > > >  	struct nlattr *na_vlan_id =3D NULL;
> > > > >  	struct nlattr *na_vlan_priority =3D NULL;
> > > > > +	uint64_t item_flags =3D 0;
> > > > > =20
> > > > >  	claim_nonzero(flow_tcf_build_ptoi_table(dev, ptoi,
> > > > >  						PTOI_TABLE_SZ_MAX(dev)));
> > > > > @@ -1189,6 +1531,7 @@ flow_tcf_translate(struct rte_eth_dev *dev,=
 struct mlx5_flow *dev_flow,
> > > > >  			}
> > > > >  			break;
> > > > >  		case RTE_FLOW_ITEM_TYPE_UDP:
> > > > > +			item_flags |=3D MLX5_FLOW_LAYER_OUTER_L4_UDP;
> > > >=20
> > > > Let's add the same to the rest of items like flow_tcf_validate().
> > > >=20
> > > OK!
> > > >=20
> > > > Thanks,
> > > > Yongseok
> > > >=20
> > > > >  			mask.udp =3D flow_tcf_item_mask
> > > > >  				(items, &rte_flow_item_udp_mask,
> > > > >  				 &flow_tcf_mask_supported.udp,
> > > > > @@ -1218,6 +1561,7 @@ flow_tcf_translate(struct rte_eth_dev *dev,=
 struct mlx5_flow *dev_flow,
> > > > >  			}
> > > > >  			break;
> > > > >  		case RTE_FLOW_ITEM_TYPE_TCP:
> > > > > +			item_flags |=3D MLX5_FLOW_LAYER_OUTER_L4_TCP;
> > > > >  			mask.tcp =3D flow_tcf_item_mask
> > > > >  				(items, &rte_flow_item_tcp_mask,
> > > > >  				 &flow_tcf_mask_supported.tcp,
> > > > > @@ -1368,6 +1712,18 @@ flow_tcf_translate(struct rte_eth_dev *dev=
, struct mlx5_flow *dev_flow,
> > > > >  					conf.of_set_vlan_pcp->vlan_pcp;
> > > > >  			}
> > > > >  			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:
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_IPV6_DST:
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_TP_SRC:
> > > > > +		case RTE_FLOW_ACTION_TYPE_SET_TP_DST:
> > > > > +			na_act_index =3D
> > > > > +				mnl_attr_nest_start(nlh, na_act_index_cur++);
> > > > > +			flow_tcf_create_pedit_mnl_msg(nlh,
> > > > > +						      &actions, item_flags);
> > > > > +			mnl_attr_nest_end(nlh, na_act_index);
> > > > > +			break;
> > > > >  		default:
> > > > >  			return rte_flow_error_set(error, ENOTSUP,
> > > > >  						  RTE_FLOW_ERROR_TYPE_ACTION,
> > > > > --=20
> > > > > 2.17.1
> > > > >=20