From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 6E41A1D0F2 for ; Fri, 6 Apr 2018 15:44:31 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2018 06:44:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,415,1517904000"; d="scan'208";a="43999819" Received: from awalabdu-mobl.ger.corp.intel.com (HELO [163.33.228.156]) ([163.33.228.156]) by fmsmga004.fm.intel.com with ESMTP; 06 Apr 2018 06:44:27 -0700 To: Thomas Monjalon , Declan Doherty Cc: dev@dpdk.org, Alex Rosenbaum , Ferruh Yigit , Shahaf Shuler , Qi Zhang , Alejandro Lucero , Andrew Rybchenko , Remy Horton , John McNamara , Rony Efraim , Jingjing Wu , Wenzhuo Lu , Yuanhan Liu , Bruce Richardson References: <20180405135148.16388-1-declan.doherty@intel.com> <20180405135148.16388-3-declan.doherty@intel.com> <6080546.OoGlZRrAI8@xps> From: Mohammad Abdul Awal Message-ID: Date: Fri, 6 Apr 2018 14:44:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <6080546.OoGlZRrAI8@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v2 2/4] ethdev: Add vTEP encap/decap actions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 13:44:32 -0000 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.