From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
Subject: Re: [PATCH v2 2/4] ethdev: Add vTEP encap/decap actions
Date: Fri, 6 Apr 2018 14:44:25 +0100
Message-ID: <ad6878bd-ba8c-aeff-1ba3-946f054d12fb@intel.com>
References: <20180405135148.16388-1-declan.doherty@intel.com>
 <20180405135148.16388-3-declan.doherty@intel.com> <6080546.OoGlZRrAI8@xps>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org, Alex Rosenbaum <alexr@mellanox.com>,
 Ferruh Yigit <ferruh.yigit@intel.com>, Shahaf Shuler <shahafs@mellanox.com>,
 Qi Zhang <qi.z.zhang@intel.com>,
 Alejandro Lucero <alejandro.lucero@netronome.com>,
 Andrew Rybchenko <arybchenko@solarflare.com>,
 Remy Horton <remy.horton@intel.com>, John McNamara
 <john.mcnamara@intel.com>, Rony Efraim <ronye@mellanox.com>,
 Jingjing Wu <jingjing.wu@intel.com>, Wenzhuo Lu <wenzhuo.lu@intel.com>,
 Yuanhan Liu <yliu@fridaylinux.org>,
 Bruce Richardson <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
 Declan Doherty <declan.doherty@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga18.intel.com (mga18.intel.com [134.134.136.126])
 by dpdk.org (Postfix) with ESMTP id 6E41A1D0F2
 for <dev@dpdk.org>; Fri,  6 Apr 2018 15:44:31 +0200 (CEST)
In-Reply-To: <6080546.OoGlZRrAI8@xps>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>


On 05/04/2018 17:42, Thomas Monjalon wrote:
> 05/04/2018 15:51, Declan Doherty:
>> +/**
>> + * RTE_FLOW_ACTION_TYPE_VTEP_ENCAP
>> + *
>> + * Virtual tunnel end-point encapsulation action data.
>> + *
>> + * Non-terminating action by default.
>> + */
>> +struct rte_flow_action_vtep_encap {
>> +	struct rte_flow_action_item {
>> +		enum rte_flow_item_type type;
>> +		/**< Flow item type. */
>> +		const void *item;
>> +		/**< Flow item definition. */
>> +	} *pattern;
>> +	/**<
>> +	 * vTEP pattern specification (list terminated by the END pattern item).
>> +	 */
>> +};
>> +
>> +/**
>> + * RTE_FLOW_ACTION_TYP_VTEP_DECAP
>> + *
>> + * Virtual tunnel end-point decapsulation action data.
>> + *
>> + * Non-terminating action by default.
>> + */
>> +struct rte_flow_action_vtep_decap {
>> +	enum rte_flow_item_type type;
>> +	/**<
>> +	 * Flow item type of virtual tunnel end-point to be decapsulated
>> +	 */
>> +};
> Question about the naming:
> Why using the terminology VTEP instead of TUNNEL simply?
> I probably miss something, but tunnel encap/decap looks simpler to me.

Initial thought was that the tunnel terminology may conflict with 
existing tunnel item types and their uses. In previous terminologies, it 
was assumed that to create a tunneled flows, each time a tunnel item has 
to be specified in the patterns.
Now with the endpoint concept, the tunnel endpoint will be created once 
only, in for each subsequent flows created that is supposed to use the 
tunnel, will use the tunnel metadata during the flow creation. Hence 
comes the terminology virtual tunnel endpoint (VTEP). It does not harm 
to use tunnel instead of vtep except the endpoint term is mission. In 
the next patch TUNNEL terminology is used instead of VTEP.