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.zh...@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?
