[dpdk-dev,v7,1/5] lib/librte_ether: change function name of tunnel port config
Commit Message
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 <wenzhuo.lu@intel.com>
---
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(-)
Comments
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.
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, March 9, 2016 7:35 AM
> To: Lu, Wenzhuo
> Cc: dev@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.
2016-03-09 00:53, Lu, Wenzhuo:
> From: Thomas Monjalon [mailto:thomas.monjalon@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.
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, March 9, 2016 9:04 AM
> To: Lu, Wenzhuo
> Cc: dev@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@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 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.
>
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.
2016-03-09 01:25, Lu, Wenzhuo:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2016-03-09 00:53, Lu, Wenzhuo:
> > > From: Thomas Monjalon [mailto:thomas.monjalon@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.
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, March 9, 2016 5:32 PM
> To: Lu, Wenzhuo
> Cc: dev@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@6wind.com]
> > > 2016-03-09 00:53, Lu, Wenzhuo:
> > > > From: Thomas Monjalon [mailto:thomas.monjalon@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.
@@ -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));
@@ -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]);
@@ -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;
@@ -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 port */
+
#ifdef RTE_NIC_BYPASS
enum {
@@ -1443,6 +1451,10 @@ struct eth_dev_ops {
eth_timesync_read_time timesync_read_time;
/** Set the device clock time. */
eth_timesync_write_time timesync_write_time;
+ /** Add UDP tunnel port. */
+ eth_udp_tunnel_port_add_t udp_tunnel_port_add;
+ /** Del UDP tunnel port. */
+ eth_udp_tunnel_port_del_t udp_tunnel_port_del;
};
/**
@@ -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);
+int
+rte_eth_dev_udp_tunnel_port_add(uint8_t port_id,
+ struct rte_eth_udp_tunnel *tunnel_udp);
/**
* 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);
/**
* Check whether the filter type is supported on an Ethernet device.
@@ -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: *;
};