From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jack Min <jackmin@mellanox.com>
Subject: Re: [PATCH v5 1/3] ethdev: add generic TTL rewrite
	actions
Date: Tue, 16 Oct 2018 02:03:35 +0000
Message-ID: <20181016020318.2efwbgg2ghgawa3e@MTBC-JACKMIN.mtl.com>
References: <20181011132641.1000-1-jackmin@mellanox.com>
 <20181013032348.26380-1-jackmin@mellanox.com>
 <20181013032348.26380-2-jackmin@mellanox.com>
 <ef0d8364-39ce-8227-493e-8f3f29109093@solarflare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: Adrien Mazarguil <adrien.mazarguil@6wind.com>, John McNamara
 <john.mcnamara@intel.com>, Marko Kovacevic <marko.kovacevic@intel.com>,
 Thomas Monjalon <thomas@monjalon.net>, Ferruh Yigit <ferruh.yigit@intel.com>,
 "dev@dpdk.org" <dev@dpdk.org>
To: Andrew Rybchenko <arybchenko@solarflare.com>
Return-path: <dev-bounces@dpdk.org>
Received: from EUR02-AM5-obe.outbound.protection.outlook.com
 (mail-eopbgr00058.outbound.protection.outlook.com [40.107.0.58])
 by dpdk.org (Postfix) with ESMTP id B58194C96
 for <dev@dpdk.org>; Tue, 16 Oct 2018 04:03:38 +0200 (CEST)
In-Reply-To: <ef0d8364-39ce-8227-493e-8f3f29109093@solarflare.com>
Content-Language: en-US
Content-ID: <B6BF8C641A423848B465BA365704E315@eurprd05.prod.outlook.com>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 18-10-14 10:35:30, Andrew Rybchenko wrote:
> On 13.10.2018 06:24, Jack Min wrote:
> > rewrite TTL by decrease or just set it directly
> > it's not necessary to check if the final result
> > is zero or not
> >=20
> > This is slightly different from the one defined
> > by openflow and more generic
> >=20
> > Signed-off-by: Xiaoyu Min <jackmin@mellanox.com>
> > Acked-by: Yongseok Koh <yskoh@mellanox.com>
> > ---
>=20
> [...]
>=20
> > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.=
h
> > index 68bbf57d0..f102e6939 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -1579,6 +1579,26 @@ enum rte_flow_action_type {
> >   	 * No associated configuration structure.
> >   	 */
> >   	RTE_FLOW_ACTION_TYPE_MAC_SWAP,
> > +
> > +	/**
> > +	 * Decrease TTL value directly
> > +	 *
> > +	 * If flow pattern doesn't define a valid RTE_FLOW_ITEM_TYPE_IPV4, or
> > +	 * RTE_FLOW_ITEM_TYPE_IPV6, the PMD should return a
> > +	 * RTE_FLOW_ERROR_TYPE_ACTION error.
> > +	 */
> > +	RTE_FLOW_ACTION_TYPE_DEC_TTL,
> > +
> > +	/**
> > +	 * Set TTL value
> > +	 *
> > +	 * If flow pattern doesn't define a valid RTE_FLOW_ITEM_TYPE_IPV4, or
> > +	 * RTE_FLOW_ITEM_TYPE_IPV6, the PMD should return a
> > +	 * RTE_FLOW_ERROR_TYPE_ACTION error.
> > +	 *
> > +	 * See struct rte_flow_action_set_ttl
> > +	 */
> > +	RTE_FLOW_ACTION_TYPE_SET_TTL,
> >   };
> >   /**
>=20
> As I understand it is one more case where the following note from Adrien
> is applicable [1]:
>=20
> <begin quote>
>=20
> Another problem is that you must not require actions to rely on specific
> pattern content:
>=20
>  [...]
>  *
>  * Decapsulate outer most tunnel from matched flow.
>  *
>  * The flow pattern must have a valid tunnel header
>  */
>  RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP,
>=20
> For maximum flexibility, all actions should be usable on their own on emp=
ty
> pattern. On the other hand, you can document undefined behavior when
> performing some action on traffic that doesn't contain something.
>=20
> Reason is that invalid traffic may have already been removed by other flo=
w
> rules (or whatever happens) before such a rule is reached; it's a user's
> responsibility to provide such guarantee.
>=20
> When parsing an action, a PMD is not supposed to look at the pattern. Act=
ion
> list should contain all the needed info, otherwise it means the API is ba=
dly
> defined.
>=20
> I'm aware the above makes it tough to implement something like
> RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP as defined in this series, but that's
> unfortunately why I think it must not be defined like that.
>=20
> <end quote>
>=20
> [1] https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F=
mails.dpdk.org%2Farchives%2Fdev%2F2018-October%2F115267.html&amp;data=3D02%=
7C01%7Cjackmin%40mellanox.com%7C8297d07c910e4aa6b4f508d631a7ab8e%7Ca652971c=
7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636750993538615097&amp;sdata=3Dq0ywvMqqt=
Rr%2BHp%2FBHLGtMF3x84kwPooZ7eYfdxmHtUs%3D&amp;reserved=3D0
>=20
Alright, I'will document this as PMD's limitation not API's.

-Jack