From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 51B9CA0A04; Fri, 15 Jan 2021 16:51:58 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C95E714118F; Fri, 15 Jan 2021 16:51:57 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id CAD8E14118D for ; Fri, 15 Jan 2021 16:51:56 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 364065C0103; Fri, 15 Jan 2021 10:51:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 15 Jan 2021 10:51:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= A0Ulm5iqFsohrve6tzUyR+vOfYeUwwX0y//tSlc/vos=; b=zWDitYCWgxq//0I/ 7H+V/GvRwbUilLUSDelMz+bjHCU8eHZxC5lwla/m0JZWhM9yJnnLc9THPxe6wnFT lEfixv59paAb0MAy7gpZ1+OeLglWn6quzslseJUrYxlW2MnYVx+A/krgVrNMwjPI 9tZEs2N9uyMmtvfSirH2N+UyrjAT0wY9AvS1rvPZWo1oURBUscnP85mo5WyYHpbn laH7T+3C1j8+YldzOytnu8xupx4cE+ROBr1b6TB/i1X2a/d4NJ9PvVAolJP+J2g+ m7NWU704anpuKzt04XYqnZnikEDmBQKOpGJV02Re6PuclzjBCG2gS0t0LbdROeCi e88DNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=A0Ulm5iqFsohrve6tzUyR+vOfYeUwwX0y//tSlc/v os=; b=e42T0Nws1lDkqH1plJcc88lMkh6zHB6lenX1O/bAq5r2IOe7sotAMSVpj PRpbX9xadlv0N5gmAdto4H2/ZFKbESx+eD3iipOw/fOUIZHi0xG2dl6iVleh2dSP iDbZF9HscRmGp1xz3vRqNa3v7iKnN11hQZ9UEPIn7JYr6Mdz6k+/YY6rHh9wizIE KNUJ1j3dcI9SRTS1dxAcI3LFRpTIH85nnlM65ovryCgkUOVlc0iJHCiQq56t4csQ +JiID3i8OXYMnWZZTCALIvcxg1Lx011Y/lKEiqVmL0Nl7x19K+OBWq5YZonPa5ce J37vp6rsnNtiKmgBhlgnb466O7P4Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtddvgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2C26E240065; Fri, 15 Jan 2021 10:51:53 -0500 (EST) From: Thomas Monjalon To: Qi Zhang 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 Date: Fri, 15 Jan 2021 16:51:52 +0100 Message-ID: <4389911.iuVQrazR7g@thomas> In-Reply-To: <20210112114703.350878-1-qi.z.zhang@intel.com> References: <20210112114703.350878-1-qi.z.zhang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] ethdev: refine API description X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > --- > --- 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?