[dpdk-dev] [PATCH v7 1/5] lib/librte_ether: change function name of tunnel port config
Hi Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Wednesday, March 9, 2016 5:32 PM > To: Lu, Wenzhuo > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v7 1/5] lib/librte_ether: change function name > of tunnel port config > > 2016-03-09 01:25, Lu, Wenzhuo: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2016-03-09 00:53, Lu, Wenzhuo: > > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > > 2016-03-04 10:35, Wenzhuo Lu: > > > > > > The names of function for tunnel port configuration are not > > > > > > accurate. > > > > > > They're tunnel_add/del, better change them to tunnel_port_add/del. > > > > > > > > > > As a lot of ethdev API, it is really badly documented. > > > > > > > > > > Please explain why this renaming and let's try to reword the > > > > > doxygen: > > > > > * Add UDP tunneling port of an Ethernet device for filtering a > > > > > specific > > > > > * tunneling packet by UDP port number. > > > > > > > > As we discussed before, these APIs only change the UDP port value > > > > of the > > > tunnel. > > > > But according to their names, seems like they're trying to > > > > add/delete a whole > > > tunnel. > > > > The names don't tell us what the functions really do, so we want > > > > to change the > > > names. > > > > > > Neither the comment nor the name explain what means filtering here. > > > I think we should explain more. > > > We add a port number and a protocol type. What is it made for? > > > > Prot_type means the tunnel type, VxLAN, GENEVE.., actually it's > rte_eth_tunnel_type. > > Udp_port means the UDP port value used for the specific type of tunnel. > > I'll add some comments in the structure. > > OK but we really need you explain in the doxygen what the NIC is expected to > do > with these informations. I think it's so clear in your head that you don't > think the > users don't understand what the tunnel offloading means. I'll add more info here. Thanks.
[dpdk-dev] [PATCH v7 1/5] lib/librte_ether: change function name of tunnel port config
2016-03-09 01:25, Lu, Wenzhuo: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2016-03-09 00:53, Lu, Wenzhuo: > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > 2016-03-04 10:35, Wenzhuo Lu: > > > > > The names of function for tunnel port configuration are not accurate. > > > > > They're tunnel_add/del, better change them to tunnel_port_add/del. > > > > > > > > As a lot of ethdev API, it is really badly documented. > > > > > > > > Please explain why this renaming and let's try to reword the > > > > doxygen: > > > > * Add UDP tunneling port of an Ethernet device for filtering a > > > > specific > > > > * tunneling packet by UDP port number. > > > > > > As we discussed before, these APIs only change the UDP port value of the > > tunnel. > > > But according to their names, seems like they're trying to add/delete a > > > whole > > tunnel. > > > The names don't tell us what the functions really do, so we want to > > > change the > > names. > > > > Neither the comment nor the name explain what means filtering here. > > I think we should explain more. > > We add a port number and a protocol type. What is it made for? > > Prot_type means the tunnel type, VxLAN, GENEVE.., actually it's > rte_eth_tunnel_type. > Udp_port means the UDP port value used for the specific type of tunnel. > I'll add some comments in the structure. OK but we really need you explain in the doxygen what the NIC is expected to do with these informations. I think it's so clear in your head that you don't think the users don't understand what the tunnel offloading means.
[dpdk-dev] [PATCH v7 1/5] lib/librte_ether: change function name of tunnel port config
Hi Thomas, > > > > > > > > You must move it below the doxygen comment. > > > OK. Honestly, I'd like to act like that. But seems the style is to > > > put the function above the comment.(Don't know the reason.) > > > > Do you mean the function below the comment? > No, I really mean above. Like this, > typedef int (*eth_get_reg_t)(struct rte_eth_dev *dev, > struct rte_dev_reg_info *info); > /**< @internal Retrieve registers */ > > typedef int (*eth_get_eeprom_length_t)(struct rte_eth_dev *dev); /**< > @internal Retrieve eeprom size */ > > typedef int (*eth_get_eeprom_t)(struct rte_eth_dev *dev, > struct rte_dev_eeprom_info *info); > /**< @internal Retrieve eeprom data */ > > typedef int (*eth_set_eeprom_t)(struct rte_eth_dev *dev, > struct rte_dev_eeprom_info *info); > /**< @internal Program eeprom data */ Sorry, I misunderstood you. I'll do what you suggested.
[dpdk-dev] [PATCH v7 1/5] lib/librte_ether: change function name of tunnel port config
2016-03-09 00:53, Lu, Wenzhuo:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > 2016-03-04 10:35, Wenzhuo Lu:
> > > The names of function for tunnel port configuration are not accurate.
> > > They're tunnel_add/del, better change them to tunnel_port_add/del.
> >
> > As a lot of ethdev API, it is really badly documented.
> >
> > Please explain why this renaming and let's try to reword the
> > doxygen:
> > * Add UDP tunneling port of an Ethernet device for filtering a specific
> > * tunneling packet by UDP port number.
>
> As we discussed before, these APIs only change the UDP port value of the
> tunnel.
> But according to their names, seems like they're trying to add/delete a whole
> tunnel.
> The names don't tell us what the functions really do, so we want to change
> the names.
Neither the comment nor the name explain what means filtering here.
I think we should explain more.
We add a port number and a protocol type. What is it made for?
> > Please what are the values of
> > struct rte_eth_udp_tunnel {
> > uint16_t udp_port;
> > uint8_t prot_type;
> > };
>
> > When I see an API struct without any comment, I feel it must be dropped.
> I'm confused. I don't do anything about this structure. You want me to add
> more comments for it?
Yes please, comment at least prot_type. Which values to set?
Any reference to some constants?
> > By the way, it is yet another filtering API, so it must be totally reworked.
>
> Not quite understand. I only try to change the name. If rework needed, could
> we do this with a new patch?
I know you are trying to improve the situation :)
I'm just saying that the whole filtering APIs suck and we need to re-think it.
But it's another discussion. Let's improve this one for 16.04 while talking
about future design in other threads.
> > > As it may be an ABI change if change the names directly, the new
> > > functions are added but not remove the old ones. The old ones will be
> > > removed in the next release after an ABI change announcement.
> >
> > Please make the announce in this patch.
>
> Sure, I'll do that.
Thanks
> > > --- a/lib/librte_ether/rte_ethdev.h
> > > +++ b/lib/librte_ether/rte_ethdev.h
> > > @@ -3403,6 +3415,9 @@ rte_eth_dev_rss_hash_conf_get(uint8_t port_id,
> > > int rte_eth_dev_udp_tunnel_add(uint8_t port_id,
> > > struct rte_eth_udp_tunnel *tunnel_udp);
> >
> > You must deprecate this one and put a comment above with something like
> > @see rte_eth_dev_udp_tunnel_port_add.
> I'll add this. Thanks.
>
> >
> > > +int
> > > +rte_eth_dev_udp_tunnel_port_add(uint8_t port_id,
> > > + struct rte_eth_udp_tunnel *tunnel_udp);
> >
> > You must move it below the doxygen comment.
> OK. Honestly, I'd like to act like that. But seems the style is to put the
> function above the comment.(Don't know the reason.)
Do you mean the function below the comment?
> It'll be a little strange if I do something different.
Just check the doxygen output.
We must have the comments associated with the new function
and a deprecation comment with the old one.
> > > --- a/lib/librte_ether/rte_ether_version.map
> > > +++ b/lib/librte_ether/rte_ether_version.map
> > > @@ -114,6 +114,8 @@ DPDK_2.2 {
> > > rte_eth_tx_queue_setup;
> > > rte_eth_xstats_get;
> > > rte_eth_xstats_reset;
> > > + rte_eth_dev_udp_tunnel_port_add;
> > > + rte_eth_dev_udp_tunnel_port_delete;
> > >
> > > local: *;
> > > };
> >
> > Panu already made a comment about adding a new section for 16.04.
>
> Thanks for the info. Let me follow it.
[dpdk-dev] [PATCH v7 1/5] lib/librte_ether: change function name of tunnel port config
Hi Thomas,
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, March 9, 2016 9:04 AM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 1/5] lib/librte_ether: change function name
> of tunnel port config
>
> 2016-03-09 00:53, Lu, Wenzhuo:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > 2016-03-04 10:35, Wenzhuo Lu:
> > > > The names of function for tunnel port configuration are not accurate.
> > > > They're tunnel_add/del, better change them to tunnel_port_add/del.
> > >
> > > As a lot of ethdev API, it is really badly documented.
> > >
> > > Please explain why this renaming and let's try to reword the
> > > doxygen:
> > > * Add UDP tunneling port of an Ethernet device for filtering a
> > > specific
> > > * tunneling packet by UDP port number.
> >
> > As we discussed before, these APIs only change the UDP port value of the
> tunnel.
> > But according to their names, seems like they're trying to add/delete a
> > whole
> tunnel.
> > The names don't tell us what the functions really do, so we want to change
> > the
> names.
>
> Neither the comment nor the name explain what means filtering here.
> I think we should explain more.
> We add a port number and a protocol type. What is it made for?
Prot_type means the tunnel type, VxLAN, GENEVE.., actually it's
rte_eth_tunnel_type.
Udp_port means the UDP port value used for the specific type of tunnel.
I'll add some comments in the structure.
>
> > > Please what are the values of
> > > struct rte_eth_udp_tunnel {
> > > uint16_t udp_port;
> > > uint8_t prot_type;
> > > };
> >
> > > When I see an API struct without any comment, I feel it must be dropped.
> > I'm confused. I don't do anything about this structure. You want me to add
> more comments for it?
>
> Yes please, comment at least prot_type. Which values to set?
> Any reference to some constants?
I think I've explained this above.
>
> > > By the way, it is yet another filtering API, so it must be totally
> > > reworked.
> >
> > Not quite understand. I only try to change the name. If rework needed, could
> we do this with a new patch?
>
> I know you are trying to improve the situation :) I'm just saying that the
> whole
> filtering APIs suck and we need to re-think it.
> But it's another discussion. Let's improve this one for 16.04 while talking
> about
> future design in other threads.
Great :)
>
> > > > As it may be an ABI change if change the names directly, the new
> > > > functions are added but not remove the old ones. The old ones will
> > > > be removed in the next release after an ABI change announcement.
> > >
> > > Please make the announce in this patch.
> >
> > Sure, I'll do that.
>
> Thanks
>
> > > > --- a/lib/librte_ether/rte_ethdev.h
> > > > +++ b/lib/librte_ether/rte_ethdev.h
> > > > @@ -3403,6 +3415,9 @@ rte_eth_dev_rss_hash_conf_get(uint8_t
> > > > port_id, int rte_eth_dev_udp_tunnel_add(uint8_t port_id,
> > > >struct rte_eth_udp_tunnel *tunnel_udp);
> > >
> > > You must deprecate this one and put a comment above with something
> > > like @see rte_eth_dev_udp_tunnel_port_add.
> > I'll add this. Thanks.
> >
> > >
> > > > +int
> > > > +rte_eth_dev_udp_tunnel_port_add(uint8_t port_id,
> > > > + struct rte_eth_udp_tunnel *tunnel_udp);
> > >
> > > You must move it below the doxygen comment.
> > OK. Honestly, I'd like to act like that. But seems the style is to put
> > the function above the comment.(Don't know the reason.)
>
> Do you mean the function below the comment?
No, I really mean above. Like this,
typedef int (*eth_get_reg_t)(struct rte_eth_dev *dev,
struct rte_dev_reg_info *info);
/**< @internal Retrieve registers */
typedef int (*eth_get_eeprom_length_t)(struct rte_eth_dev *dev);
/**< @internal Retrieve eeprom size */
typedef int (*eth_get_eeprom_t)(struct rte_eth_dev *dev,
struct rte_dev_eeprom_info *info);
/**< @internal Retrieve eeprom data */
typedef int (*eth_set_eeprom_t)(struct rte_eth_dev *dev,
struct rte_dev_eeprom_info *info);
/**< @internal Program eeprom data */
>
> > It'll be a little strange if I
[dpdk-dev] [PATCH v7 1/5] lib/librte_ether: change function name of tunnel port config
Hi Thomas,
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, March 9, 2016 7:35 AM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 1/5] lib/librte_ether: change function name
> of tunnel port config
>
> 2016-03-04 10:35, Wenzhuo Lu:
> > The names of function for tunnel port configuration are not accurate.
> > They're tunnel_add/del, better change them to tunnel_port_add/del.
>
> As a lot of ethdev API, it is really badly documented.
>
> Please explain why this renaming and let's try to reword the
> doxygen:
> * Add UDP tunneling port of an Ethernet device for filtering a specific
> * tunneling packet by UDP port number.
As we discussed before, these APIs only change the UDP port value of the
tunnel.
But according to their names, seems like they're trying to add/delete a whole
tunnel.
The names don't tell us what the functions really do, so we want to change the
names.
>
> Please what are the values of
> struct rte_eth_udp_tunnel {
> uint16_t udp_port;
> uint8_t prot_type;
> };
> When I see an API struct without any comment, I feel it must be dropped.
I'm confused. I don't do anything about this structure. You want me to add
more comments for it?
>
> By the way, it is yet another filtering API, so it must be totally reworked.
Not quite understand. I only try to change the name. If rework needed, could we
do this with a new patch?
>
> > As it may be an ABI change if change the names directly, the new
> > functions are added but not remove the old ones. The old ones will be
> > removed in the next release after an ABI change announcement.
>
> Please make the announce in this patch.
Sure, I'll do that.
>
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -3403,6 +3415,9 @@ rte_eth_dev_rss_hash_conf_get(uint8_t port_id,
> > int rte_eth_dev_udp_tunnel_add(uint8_t port_id,
> >struct rte_eth_udp_tunnel *tunnel_udp);
>
> You must deprecate this one and put a comment above with something like
> @see rte_eth_dev_udp_tunnel_port_add.
I'll add this. Thanks.
>
> > +int
> > +rte_eth_dev_udp_tunnel_port_add(uint8_t port_id,
> > + struct rte_eth_udp_tunnel *tunnel_udp);
>
> You must move it below the doxygen comment.
OK. Honestly, I'd like to act like that. But seems the style is to put the
function above the comment.(Don't know the reason.)
It'll be a little strange if I do something different.
> >
> > /**
> > * Detete UDP tunneling port configuration of Ethernet device @@
> > -3420,6 +3435,9 @@ rte_eth_dev_udp_tunnel_add(uint8_t port_id, int
> > rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
> > struct rte_eth_udp_tunnel *tunnel_udp);
> > +int
> > +rte_eth_dev_udp_tunnel_port_delete(uint8_t port_id,
> > + struct rte_eth_udp_tunnel *tunnel_udp);
>
> idem
>
> > --- a/lib/librte_ether/rte_ether_version.map
> > +++ b/lib/librte_ether/rte_ether_version.map
> > @@ -114,6 +114,8 @@ DPDK_2.2 {
> > rte_eth_tx_queue_setup;
> > rte_eth_xstats_get;
> > rte_eth_xstats_reset;
> > + rte_eth_dev_udp_tunnel_port_add;
> > + rte_eth_dev_udp_tunnel_port_delete;
> >
> > local: *;
> > };
>
> Panu already made a comment about adding a new section for 16.04.
Thanks for the info. Let me follow it.
[dpdk-dev] [PATCH v7 1/5] lib/librte_ether: change function name of tunnel port config
2016-03-04 10:35, Wenzhuo Lu:
> The names of function for tunnel port configuration are not
> accurate. They're tunnel_add/del, better change them to
> tunnel_port_add/del.
As a lot of ethdev API, it is really badly documented.
Please explain why this renaming and let's try to reword the
doxygen:
* Add UDP tunneling port of an Ethernet device for filtering a specific
* tunneling packet by UDP port number.
Please what are the values of
struct rte_eth_udp_tunnel {
uint16_t udp_port;
uint8_t prot_type;
};
When I see an API struct without any comment, I feel it must be dropped.
By the way, it is yet another filtering API, so it must be totally reworked.
> As it may be an ABI change if change the names directly, the
> new functions are added but not remove the old ones. The old
> ones will be removed in the next release after an ABI change
> announcement.
Please make the announce in this patch.
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -3403,6 +3415,9 @@ rte_eth_dev_rss_hash_conf_get(uint8_t port_id,
> int
> rte_eth_dev_udp_tunnel_add(uint8_t port_id,
> struct rte_eth_udp_tunnel *tunnel_udp);
You must deprecate this one and put a comment above
with something like @see rte_eth_dev_udp_tunnel_port_add.
> +int
> +rte_eth_dev_udp_tunnel_port_add(uint8_t port_id,
> + struct rte_eth_udp_tunnel *tunnel_udp);
You must move it below the doxygen comment.
>
> /**
> * Detete UDP tunneling port configuration of Ethernet device
> @@ -3420,6 +3435,9 @@ rte_eth_dev_udp_tunnel_add(uint8_t port_id,
> int
> rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
> struct rte_eth_udp_tunnel *tunnel_udp);
> +int
> +rte_eth_dev_udp_tunnel_port_delete(uint8_t port_id,
> +struct rte_eth_udp_tunnel *tunnel_udp);
idem
> --- a/lib/librte_ether/rte_ether_version.map
> +++ b/lib/librte_ether/rte_ether_version.map
> @@ -114,6 +114,8 @@ DPDK_2.2 {
> rte_eth_tx_queue_setup;
> rte_eth_xstats_get;
> rte_eth_xstats_reset;
> + rte_eth_dev_udp_tunnel_port_add;
> + rte_eth_dev_udp_tunnel_port_delete;
>
> local: *;
> };
Panu already made a comment about adding a new section for 16.04.
[dpdk-dev] [PATCH v7 1/5] lib/librte_ether: change function name of tunnel port config
The names of function for tunnel port configuration are not
accurate. They're tunnel_add/del, better change them to
tunnel_port_add/del.
As it may be an ABI change if change the names directly, the
new functions are added but not remove the old ones. The old
ones will be removed in the next release after an ABI change
announcement.
Signed-off-by: Wenzhuo Lu
---
app/test-pmd/cmdline.c | 6 +++--
examples/tep_termination/vxlan_setup.c | 2 +-
lib/librte_ether/rte_ethdev.c | 45 ++
lib/librte_ether/rte_ethdev.h | 18 ++
lib/librte_ether/rte_ether_version.map | 2 ++
5 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 52e9f5f..0fae655 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6782,9 +6782,11 @@ cmd_tunnel_udp_config_parsed(void *parsed_result,
tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN;
if (!strcmp(res->what, "add"))
- ret = rte_eth_dev_udp_tunnel_add(res->port_id, &tunnel_udp);
+ ret = rte_eth_dev_udp_tunnel_port_add(res->port_id,
+ &tunnel_udp);
else
- ret = rte_eth_dev_udp_tunnel_delete(res->port_id, &tunnel_udp);
+ ret = rte_eth_dev_udp_tunnel_port_delete(res->port_id,
+&tunnel_udp);
if (ret < 0)
printf("udp tunneling add error: (%s)\n", strerror(-ret));
diff --git a/examples/tep_termination/vxlan_setup.c
b/examples/tep_termination/vxlan_setup.c
index 51ad133..8836603 100644
--- a/examples/tep_termination/vxlan_setup.c
+++ b/examples/tep_termination/vxlan_setup.c
@@ -191,7 +191,7 @@ vxlan_port_init(uint8_t port, struct rte_mempool *mbuf_pool)
/* Configure UDP port for UDP tunneling */
tunnel_udp.udp_port = udp_port;
tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN;
- retval = rte_eth_dev_udp_tunnel_add(port, &tunnel_udp);
+ retval = rte_eth_dev_udp_tunnel_port_add(port, &tunnel_udp);
if (retval < 0)
return retval;
rte_eth_macaddr_get(port, &ports_eth_addr[port]);
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 1257965..937b348 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1949,6 +1949,28 @@ rte_eth_dev_udp_tunnel_add(uint8_t port_id,
}
int
+rte_eth_dev_udp_tunnel_port_add(uint8_t port_id,
+ struct rte_eth_udp_tunnel *udp_tunnel)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ if (udp_tunnel == NULL) {
+ RTE_PMD_DEBUG_TRACE("Invalid udp_tunnel parameter\n");
+ return -EINVAL;
+ }
+
+ if (udp_tunnel->prot_type >= RTE_TUNNEL_TYPE_MAX) {
+ RTE_PMD_DEBUG_TRACE("Invalid tunnel type\n");
+ return -EINVAL;
+ }
+
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->udp_tunnel_port_add, -ENOTSUP);
+ return (*dev->dev_ops->udp_tunnel_port_add)(dev, udp_tunnel);
+}
+
+int
rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
struct rte_eth_udp_tunnel *udp_tunnel)
{
@@ -1972,6 +1994,29 @@ rte_eth_dev_udp_tunnel_delete(uint8_t port_id,
}
int
+rte_eth_dev_udp_tunnel_port_delete(uint8_t port_id,
+ struct rte_eth_udp_tunnel *udp_tunnel)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ if (udp_tunnel == NULL) {
+ RTE_PMD_DEBUG_TRACE("Invalid udp_tunnel parameter\n");
+ return -EINVAL;
+ }
+
+ if (udp_tunnel->prot_type >= RTE_TUNNEL_TYPE_MAX) {
+ RTE_PMD_DEBUG_TRACE("Invalid tunnel type\n");
+ return -EINVAL;
+ }
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->udp_tunnel_port_del, -ENOTSUP);
+ return (*dev->dev_ops->udp_tunnel_port_del)(dev, udp_tunnel);
+}
+
+int
rte_eth_led_on(uint8_t port_id)
{
struct rte_eth_dev *dev;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 16da821..f1f96c1 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1261,6 +1261,14 @@ typedef int (*eth_set_eeprom_t)(struct rte_eth_dev *dev,
struct rte_dev_eeprom_info *info);
/**< @internal Program eeprom data */
+typedef int (*eth_udp_tunnel_port_add_t)(struct rte_eth_dev *dev,
+struct rte_eth_udp_tunnel *tunnel_udp);
+/**< @internal Add tunneling UDP port */
+
+typedef int (*eth_udp_tunnel_port_del_t)(struct rte_eth_dev *dev,
+struct rte_eth_udp_tunnel *tunnel_udp);
+/**< @internal Delete tunneling UDP po
