[v4,1/5] eal: add VXLAN-GPE macro

Message ID 20190319163658.115513-2-qiming.yang@intel.com
State Superseded, archived
Delegated to: Qi Zhang
Headers show
Series
  • Supported VXLAN-GPE in i40e
Related show

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/mellanox-Performance-Testing success Performance Testing PASS
ci/intel-Performance-Testing success Performance Testing PASS
ci/Intel-compilation success Compilation OK

Commit Message

Yang, Qiming March 19, 2019, 4:36 p.m.
This patch added VXLAN-GPE macro in rte_eth_tunnel_type.

Signed-off-by: Qiming Yang <qiming.yang@intel.com>
---
 lib/librte_ethdev/rte_eth_ctrl.h | 1 +
 1 file changed, 1 insertion(+)

Comments

David Marchand March 19, 2019, 1:50 p.m. | #1
eal: in the title ? we are in ethdev.

On Tue, Mar 19, 2019 at 10:14 AM Qiming Yang <qiming.yang@intel.com> wrote:

> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
>  lib/librte_ethdev/rte_eth_ctrl.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h
> b/lib/librte_ethdev/rte_eth_ctrl.h
> index 5ea8ae2..b341634 100644
> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>         RTE_TUNNEL_TYPE_NVGRE,
>         RTE_TUNNEL_TYPE_IP_IN_GRE,
>         RTE_L2_TUNNEL_TYPE_E_TAG,
> +       RTE_TUNNEL_TYPE_VXLAN_GPE,
>         RTE_TUNNEL_TYPE_MAX,
>  };
>


Comments on this patch:
- is this the normal process to get an ethdev api update go through
dpdk-next-net-intel without an ethdev maintainer acking?
- does this patch introduce an api/abi breakage? (validate-abi.sh did not
complain, to my surprise)
Ferruh Yigit March 19, 2019, 4:34 p.m. | #2
On 3/19/2019 1:50 PM, David Marchand wrote:
> eal: in the title ? we are in ethdev.
> 
> On Tue, Mar 19, 2019 at 10:14 AM Qiming Yang <qiming.yang@intel.com> wrote:
> 
>> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>>
>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>> ---
>>  lib/librte_ethdev/rte_eth_ctrl.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h
>> b/lib/librte_ethdev/rte_eth_ctrl.h
>> index 5ea8ae2..b341634 100644
>> --- a/lib/librte_ethdev/rte_eth_ctrl.h
>> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
>> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>>         RTE_TUNNEL_TYPE_NVGRE,
>>         RTE_TUNNEL_TYPE_IP_IN_GRE,
>>         RTE_L2_TUNNEL_TYPE_E_TAG,
>> +       RTE_TUNNEL_TYPE_VXLAN_GPE,
>>         RTE_TUNNEL_TYPE_MAX,
>>  };
>>
> 
> 
> Comments on this patch:
> - is this the normal process to get an ethdev api update go through
> dpdk-next-net-intel without an ethdev maintainer acking?

No.
Vendor sub-trees are for the driver only changes.

> - does this patch introduce an api/abi breakage? (validate-abi.sh did not
> complain, to my surprise)
>

Patch

diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 5ea8ae2..b341634 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -229,6 +229,7 @@  enum rte_eth_tunnel_type {
 	RTE_TUNNEL_TYPE_NVGRE,
 	RTE_TUNNEL_TYPE_IP_IN_GRE,
 	RTE_L2_TUNNEL_TYPE_E_TAG,
+	RTE_TUNNEL_TYPE_VXLAN_GPE,
 	RTE_TUNNEL_TYPE_MAX,
 };