DPDK patches and discussions
 help / color / mirror / Atom feed
From: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	Declan Doherty <declan.doherty@intel.com>
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>
Subject: Re: [dpdk-dev] [PATCH v2 2/4] ethdev: Add vTEP encap/decap actions
Date: Fri, 6 Apr 2018 14:44:25 +0100	[thread overview]
Message-ID: <ad6878bd-ba8c-aeff-1ba3-946f054d12fb@intel.com> (raw)
In-Reply-To: <6080546.OoGlZRrAI8@xps>


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.

  reply	other threads:[~2018-04-06 13:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05 13:51 [dpdk-dev] [PATCH v2 0/4] ethdev: Additions to support vTEP encap/decap offload Declan Doherty
2018-04-05 13:51 ` [dpdk-dev] [PATCH v2 1/4] ethdev: add group counter support to rte_flow Declan Doherty
2018-04-05 16:31   ` Thomas Monjalon
2018-04-06 13:31     ` Mohammad Abdul Awal
2018-04-05 13:51 ` [dpdk-dev] [PATCH v2 2/4] ethdev: Add vTEP encap/decap actions Declan Doherty
2018-04-05 16:42   ` Thomas Monjalon
2018-04-06 13:44     ` Mohammad Abdul Awal [this message]
2018-04-05 13:51 ` [dpdk-dev] [PATCH v2 3/4] ethdev: Add group action type to rte_flow Declan Doherty
2018-04-05 13:51 ` [dpdk-dev] [PATCH v2 4/4] ethdev: Add metadata flow and action items support Declan Doherty
2018-04-05 16:49   ` Thomas Monjalon
2018-04-06 12:20     ` Adrien Mazarguil
2018-04-06 13:47     ` Mohammad Abdul Awal
2018-04-06 15:57       ` Thomas Monjalon
2018-04-06 16:58         ` Mohammad Abdul Awal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ad6878bd-ba8c-aeff-1ba3-946f054d12fb@intel.com \
    --to=mohammad.abdul.awal@intel.com \
    --cc=alejandro.lucero@netronome.com \
    --cc=alexr@mellanox.com \
    --cc=arybchenko@solarflare.com \
    --cc=bruce.richardson@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jingjing.wu@intel.com \
    --cc=john.mcnamara@intel.com \
    --cc=qi.z.zhang@intel.com \
    --cc=remy.horton@intel.com \
    --cc=ronye@mellanox.com \
    --cc=shahafs@mellanox.com \
    --cc=thomas@monjalon.net \
    --cc=wenzhuo.lu@intel.com \
    --cc=yliu@fridaylinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).