[dpdk-dev] [PATCH] ethdev: refine API description

[Thomas Monjalon]

Hi,

It seems we need to clarify how the API for UDP tunnel works
with rte_flow. Thanks for starting this patch.
I ask some questions below for writing a clear and exact API definition.

12/01/2021 12:47, Qi Zhang:
> Refine the description for rte_eth_dev_udp_tunnel_port_add.
> Claim this is an API for device (or port) level configuration.
> 
> Signed-off-by: Qi Zhang <qi.z.zhang at intel.com>
> ---
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -4030,6 +4030,16 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
>   * to change or add more UDP port for the tunnel. So the offloading function
>   * can take effect on the packets with the specific UDP port.
>   *
> + * Due to different requirements from different use cases, NICs may have a
> + * different way to identify a UDP port as a tunnel type. Some NIC takes this
> + * as a device (or port) level configure while some NIC takes this as a flow
> + * based configure.

I think this assumption is too vague to be useful.
It brings more confusion than it explains.

> + *
> + * This API is for the first case and typically it will only be implemented
> + * on a PF driver or a VF driver which have privilege right to configure for

What is a privileged VF exactly?

> + * other VFs. For the second case, a tunnel configure could be embedded in a
> + * rte_flow rule.

I suggest we make the explanation more API-oriented.

First thing to explain: this API will have effect on rte_flow rules only,
am I right?

What does it mean for a flow rule matching on a specific tunnel?
Let's take an example config:
	rte_eth_dev_udp_tunnel_port_add [UDP X] [tunnel T]
	rte_flow_create [tunnel T] [action A]
	rte_flow_create [UDP Y] [tunnel T] [action B]
Then action for these packets:
	1/ [UDP X] - no tunnel header
-> A (rte_eth_udp_tunnel skips the tunnel header check)
-> or none, tunnel header is checked according to rte_flow?
	2/ [UDP Y] - no tunnel header
-> none (flow rule requires a tunnel header)
	3/ [UDP X] [tunnel T]
-> A
	4/ [UDP Y] [tunnel T]
-> B
	5/ [UDP X] [tunnel U]
-> A (rte_eth_udp_tunnel skips the tunnel header check)
-> or none, tunnel header is checked according to rte_flow?
	6/ [UDP Y] [tunnel U]
-> none

Last question, how it plays with rte_flow_tunnel_match?
Should we replace rte_eth_udp_tunnel with rte_flow_tunnel_match?