DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Qi Zhang <qi.z.zhang@intel.com>
Cc: dev@dpdk.org, ferruh.yigit@intel.com, orika@nvidia.com,
	getelson@nvidia.com, andrew.rybchenko@oktetlabs.ru,
	ajit.khaparde@broadcom.com, jerinj@marvell.com
Subject: Re: [dpdk-dev] [PATCH] ethdev: refine API description
Date: Fri, 15 Jan 2021 16:51:52 +0100	[thread overview]
Message-ID: <4389911.iuVQrazR7g@thomas> (raw)
In-Reply-To: <20210112114703.350878-1-qi.z.zhang@intel.com>


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

  reply	other threads:[~2021-01-15 15:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-12 11:47 Qi Zhang
2021-01-15 15:51 ` Thomas Monjalon [this message]
2021-01-18  4:01   ` Zhang, Qi Z
2021-01-18  9:49     ` Thomas Monjalon
2021-01-19  0:47       ` Zhang, Qi Z
2021-01-19  3:19 ` [dpdk-dev] [PATCH v2] ethdev: refine doxygen for add UDP tunnel port API Qi Zhang
2021-01-27 11:34   ` Ferruh Yigit
2021-01-27 22:46     ` Thomas Monjalon
2021-02-03 20:02 ` [dpdk-dev] [PATCH v3 1/1] ethdev: refine doxygen comment of UDP tunnel API Thomas Monjalon
2021-02-06 10:40   ` Andrew Rybchenko
2021-02-10 11:20     ` Ferruh Yigit
2021-02-10 19:10       ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4389911.iuVQrazR7g@thomas \
    --to=thomas@monjalon.net \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=getelson@nvidia.com \
    --cc=jerinj@marvell.com \
    --cc=orika@nvidia.com \
    --cc=qi.z.zhang@intel.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).