From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dekelp@mellanox.com>
Received: from EUR04-DB3-obe.outbound.protection.outlook.com
 (mail-eopbgr60040.outbound.protection.outlook.com [40.107.6.40])
 by dpdk.org (Postfix) with ESMTP id 9F1DA98
 for <dev@dpdk.org>; Mon, 13 Aug 2018 10:03:29 +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=dj+lnGVX4wgk5NX4yNIdtaLOiSN71MnROzqs1iF7hiM=;
 b=n9BOXBl8M58AcZlJEFDs/X3S3zwi+Bzcgo6PfGZo4QTXodkcleOJbIjcsZeuE8pZnQJz5BLXS34VDTEWdnQ6B91diEiD5eIneeNhnvltvgrVn+O/ldlgIgom4AKPn8yqsdzNLnnVnY++chMUWBUTIVJ/et+uAJY+Gwyhn9RGP5I=
Received: from VI1PR05MB4224.eurprd05.prod.outlook.com (52.133.12.13) by
 VI1PR05MB1792.eurprd05.prod.outlook.com (10.165.236.142) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.1038.22; Mon, 13 Aug 2018 08:03:27 +0000
Received: from VI1PR05MB4224.eurprd05.prod.outlook.com
 ([fe80::945d:a27f:5b2f:85d0]) by VI1PR05MB4224.eurprd05.prod.outlook.com
 ([fe80::945d:a27f:5b2f:85d0%5]) with mapi id 15.20.1017.022; Mon, 13 Aug 2018
 08:03:27 +0000
From: Dekel Peled <dekelp@mellanox.com>
To: "dev@dpdk.org" <dev@dpdk.org>, Adrien Mazarguil
 <adrien.mazarguil@6wind.com>, "olivier.matz@6wind.com"
 <olivier.matz@6wind.com>
CC: Ori Kam <orika@mellanox.com>, Shahaf Shuler <shahafs@mellanox.com>
Thread-Topic: [RFC] ethdev: support metadata as flow rule criteria
Thread-Index: AQHUMtnfoKZmLsKuaEqZDNcdM8RhdKS9UDhA
Date: Mon, 13 Aug 2018 08:03:27 +0000
Message-ID: <VI1PR05MB42248D2A8FCCE4A2F4DCE8C9B6390@VI1PR05MB4224.eurprd05.prod.outlook.com>
References: <1534146418-1060-1-git-send-email-dekelp@mellanox.com>
In-Reply-To: <1534146418-1060-1-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=dekelp@mellanox.com; 
x-originating-ip: [193.47.165.251]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR05MB1792;
 6:C8lbry3itmMe1/vW2FgFFqtsTpjx3xPD6rJSIzA3m8Wn4EBJ8HY4L/i4c/Abpi1AIpRMVFjWXp3YWTBiWC6hjs9ZzrGHFn32IXffgWyobtMIJxUbBpsTA+XYVydLxHsY4wA99lMFcLYd4NesKe3TIPfKor+kIdqwyTw8xsaQuGXT2xclBqCZtq9AcEFxK7lCIIg18qzaPLrrpX/OMCkSpNag6Ud+3gyyawMlLhyfgaqWCZ+COpXthii08CipRZCUXWwfN14bpF9Fb8snfqfxvLZabYuJdsJCuapxRCgivbSgF2LVu3CLvc8W9Jn3gi12Ixxnglj3z5WUEAKgmu16oHzWAvJgsouCBcY7apfj4kIjC3hmCi6p/TK/wYOwJhKivZKZPqzSY397xJRCnFP4fxD4mWmwUtUEg0NBrxR8Lw0oeQSki534pis5vXJz83Xg0wDc9zfiT+eLVGzynx8riA==;
 5:zkzGHcsebC2OJpf59KBFRoLql0dFfHGOlnqpF7F06UXsVGvlTObs/U2ToujYUxW7M7EEQbgcqcRKKKK6inZ/v2zsyu2ig6Vb3iCrdGSEsVjqhPSEKRu8d39DI2MX0MEnlRI8BBf7qDBAkjYsE5f1tmhLLBswLVbgKzKExvarbIc=;
 7:hRbVU4OWXfVXc3sVrQeKc6xVOyGEQhXNqQ7oWU90sjHMBigU/eWFA2YoDx1p7XpZs1oGnyUkPZSwySrjbRxOWM6bz1LYAb6DWBnYdKZFUt2tt8FeM8x6x3tp++DQK2FydE+P/Pg2/WjIz50UVfcqbeEDhVo4cQzP6D2v2sZUgyffdOTOuABxJmQNeceWRi3mJ1ANbR9mzn+sgtpFUrA0P0x+bx9S/q0OupkMUgupQ6/LG6MU5Z5I9BjZS62Or61V
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 6bee3bd4-6aef-4c7e-a809-08d600f34085
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0;
 RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020);
 SRVR:VI1PR05MB1792; 
x-ms-traffictypediagnostic: VI1PR05MB1792:
x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr
x-microsoft-antispam-prvs: <VI1PR05MB17926EB8E4E85A06AAFBEBFBB6390@VI1PR05MB1792.eurprd05.prod.outlook.com>
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)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016);
 SRVR:VI1PR05MB1792; BCL:0; PCL:0; RULEID:; SRVR:VI1PR05MB1792; 
x-forefront-prvs: 07630F72AD
x-forefront-antispam-report: SFV:NSPM;
 SFS:(10009020)(376002)(346002)(396003)(39860400002)(366004)(136003)(13464003)(199004)(189003)(76176011)(9686003)(5250100002)(2501003)(7696005)(26005)(11346002)(86362001)(186003)(6116002)(3846002)(446003)(256004)(2900100001)(54906003)(25786009)(6436002)(55016002)(316002)(4326008)(68736007)(229853002)(99286004)(110136005)(53546011)(102836004)(6506007)(81156014)(8676002)(8936002)(81166006)(106356001)(33656002)(5660300001)(14454004)(97736004)(105586002)(305945005)(74316002)(53936002)(66066001)(486006)(476003)(478600001)(6246003)(2906002)(7736002)(107886003);
 DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB1792;
 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: dZGpA+o+LRSEL/f3SUB/fZWVsFOfkzPRE3HbMSJ5YV81ZOYIHjg55i/N/kinaON6g8idLDzdyVI8UXO/pqNMgaTS71mCWZryWvOxkCIeVIXBAN8g+wJUK/aQiH1YGcXTo9a8wgYcLX84q0Pa1CgiWHkwt90QwZV3Xf2i/4j1cDvjgZFMfa6RRm05XJ7NWPbfG32V3XNaoDJ1yjMA+y9idvYmY1wJL86l6mvcdzkSLUuK4ona+6Uhb/HA6exZUo3+mki4MeZHm6Z4Vx3Y2gPxsBeVtRDroVBNWhbEhmeFKQgp8jeXIJPNTj78tlyxiyPp5I2kyI/JYN8J1E/QN5iqUf5cSvEU+PnjfmdR6c1Px7Y=
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: 6bee3bd4-6aef-4c7e-a809-08d600f34085
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2018 08:03:27.7576 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB1792
Subject: Re: [dpdk-dev] [RFC] ethdev: support metadata as flow rule criteria
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, 13 Aug 2018 08:03:29 -0000

Adding relevant maintainers.
=20
> -----Original Message-----
> From: Dekel Peled [mailto:dekelp@mellanox.com]
> Sent: Monday, August 13, 2018 10:47 AM
> To: dev@dpdk.org
> Cc: Ori Kam <orika@mellanox.com>; Shahaf Shuler
> <shahafs@mellanox.com>
> Subject: [RFC] ethdev: support metadata as flow rule criteria
>=20
> Current implementation of rte_flow allows match pattern of flow rule, bas=
ed
> on packet data or header fields.
> This limits the application use of match patterns.
>=20
> For example, consider a vswitch application which controls a set of VMs,
> connected with virtio, in a fabric with overlay of VXLAN.
> Several VMs can have the same inner tuple, while the outer tuple is diffe=
rent
> and controlled by the vswitch (encap action).
> For the vswtich to be able to offload the rule to the NIC, it must use a =
unique
> match criteria, independent from the inner tuple, to perform the encap
> action.
>=20
> This RFC adds support for additional metadata to use as match pattern.
> The metadata is an opaque item, fully controlled by the application.
>=20
> The use of metadata is relevant for egress rules only.
> It can be set in the flow rule using the RTE_FLOW_ITEM_META.
>=20
> Application should set the packet metdata in the mbuf->metadata field, an=
d
> set the PKT_TX_METADATA flag in the mbuf->ol_flags.
> The NIC will use the packet metadata as match criteria for relevant flow =
rules.
>=20
> For example, to do an encap action depending on the VM id, the applicatio=
n
> needs to configure 'match on metadata' rte_flow rule with VM id as
> metadata, along with desired encap action.
> When preparing an egress data packet, application will set VM id data in
> mbuf metadata field and set PKT_TX_METADATA flag.
>=20
> PMD will send data packets to NIC, with VM id as metadata.
> Egress flow on NIC will match metadata as done with other criteria.
> Upon match on metadata (VM id) the appropriate encap action will be
> performed.
>=20
> This RFC introduces metadata item type for rte_flow
> RTE_FLOW_ITEM_META, along with corresponding struct
> rte_flow_item_meta and ol_flag PKT_TX_METADATA.
> It also enhances struct rte_mbuf with new data item, uint64_t metadata.
>=20
> Comments are welcome.
>=20
> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> ---
>  doc/guides/prog_guide/rte_flow.rst | 21 +++++++++++++++++++++
>  lib/librte_ethdev/rte_flow.c       |  1 +
>  lib/librte_ethdev/rte_flow.h       | 25 +++++++++++++++++++++++++
>  lib/librte_mbuf/rte_mbuf.h         | 11 +++++++++++
>  4 files changed, 58 insertions(+)
>=20
> diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> index b305a72..b6e35f1 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1191,6 +1191,27 @@ Normally preceded by any of:
>  - `Item: ICMP6_ND_NS`_
>  - `Item: ICMP6_ND_OPT`_
>=20
> +Item: ``META``
> +^^^^^^^^^^^^^^
> +
> +Matches an application specific 64 bit metadata item.
> +
> +- Default ``mask`` matches any 64 bit value.
> +
> +.. _table_rte_flow_item_meta:
> +
> +.. table:: META
> +
> +   +----------+----------+---------------------------+
> +   | Field    | Subfield | Value                     |
> +   +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
+
> +   | ``spec`` | ``data`` | 64 bit metadata value     |
> +   +----------+--------------------------------------+
> +   | ``last`` | ``data`` | upper range value         |
> +   +----------+----------+---------------------------+
> +   | ``mask`` | ``data`` | zeroed to match any value |
> +   +----------+----------+---------------------------+
> +
>  Actions
>  ~~~~~~~
>=20
> diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c =
index
> cff4b52..54e5ef8 100644
> --- a/lib/librte_ethdev/rte_flow.c
> +++ b/lib/librte_ethdev/rte_flow.c
> @@ -66,6 +66,7 @@ struct rte_flow_desc_data {
>  		     sizeof(struct rte_flow_item_icmp6_nd_opt_sla_eth)),
>  	MK_FLOW_ITEM(ICMP6_ND_OPT_TLA_ETH,
>  		     sizeof(struct rte_flow_item_icmp6_nd_opt_tla_eth)),
> +	MK_FLOW_ITEM(META, sizeof(struct rte_flow_item_meta)),
>  };
>=20
>  /** Generate flow_action[] entry. */
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h =
index
> f8ba71c..b81c816 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -413,6 +413,15 @@ enum rte_flow_item_type {
>  	 * See struct rte_flow_item_mark.
>  	 */
>  	RTE_FLOW_ITEM_TYPE_MARK,
> +
> +	/**
> +	 * [META]
> +	 *
> +	 * Matches a metadata value specified in mbuf metadata field.
> +	 *
> +	 * See struct rte_flow_item_meta.
> +	 */
> +	RTE_FLOW_ITEM_TYPE_META,
>  };
>=20
>  /**
> @@ -849,6 +858,22 @@ struct rte_flow_item_gre {  #endif
>=20
>  /**
> + * RTE_FLOW_ITEM_TYPE_META.
> + *
> + * Matches a specified metadata value.
> + */
> +struct rte_flow_item_meta {
> +	uint64_t data;
> +};
> +
> +/** Default mask for RTE_FLOW_ITEM_TYPE_META. */ #ifndef __cplusplus
> +static const struct rte_flow_item_meta rte_flow_item_meta_mask =3D {
> +	.data =3D RTE_BE64(UINT64_MAX),
> +};
> +#endif
> +
> +/**
>   * RTE_FLOW_ITEM_TYPE_FUZZY
>   *
>   * Fuzzy pattern match, expect faster than default.
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h inde=
x
> 9ce5d76..8f06a78 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -182,6 +182,11 @@
>  /* add new TX flags here */
>=20
>  /**
> + * This flag indicates that the metadata field in the mbuf is in use.
> + */
> +#define PKT_TX_METADATA		(1ULL << 41)
> +
> +/**
>   * UDP Fragmentation Offload flag. This flag is used for enabling UDP
>   * fragmentation in SW or in HW. When use UFO, mbuf->tso_segsz is used
>   * to store the MSS of UDP fragments.
> @@ -593,6 +598,12 @@ struct rte_mbuf {
>  	 */
>  	struct rte_mbuf_ext_shared_info *shinfo;
>=20
> +	/**
> +	 * Application specific metadata value for flow rule match.
> +	 * Valid if PKT_TX_METADATA is set.
> +	 */
> +	uint64_t metadata;
> +
>  } __rte_cache_aligned;
>=20
>  /**
> --
> 1.8.3.1