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 18ED3A0A0E; Wed, 3 Feb 2021 21:02:28 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 85A3E2404F6; Wed, 3 Feb 2021 21:02:27 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 7594D2404ED for ; Wed, 3 Feb 2021 21:02:26 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 69C255C0100; Wed, 3 Feb 2021 15:02:25 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 03 Feb 2021 15:02:25 -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; s=fm3; bh=D35bQip/JGIEP bYsQjjp4TjhCG5PjF22D4+LmvuGr2M=; b=14n8C6tPGedUBtW4tp6WeCiw/U52/ KcpgbxBebp2icLAq3xBpOJ2Lz5/i6PX/Tzj+fgaD6Hw3SnQ8CA9t7DmkLZZRbmTR 494au5T7X9zZdw+kGo3u2fgzzn0eCg40CPMyj+Y3jsBQfCgq+4r4Qx7z2NwTEBI2 RZAUohT+NOJlj5XPgW+mA/D+Nlp2Ln8Exc/Y2wGEp7ac5y7c3M+0ySDZOrhF4Eiy 5HT8Pex/n6GUa1UyZCU+uruCdKUVgEkfPPuvOha8EnmukUP9dJhCVFypgh31RGju 5HPDsua+C2UusfWez4cWgKGZPf9hKszTWlneC3g27mVtXm32QBOJQqFHg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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= fm2; bh=D35bQip/JGIEPbYsQjjp4TjhCG5PjF22D4+LmvuGr2M=; b=Le7ta21W 22dzqiegXfpaTYsgpki+rwgH+UrPafL/YyWVbY0vdEivd3jVSq/7yxJ2EX4XucEG fzXfw105EMSmdz4xfgyEXRV533XVELhYt8jVvAPfkFJy+OnPIYHaovvh3/e+7Qcz 48+JESCl0jOVzKRxCmy0HbhpqMr+ujpHwD7vr7uiprhnIaDy+/lk9mbE7kPOa/zE A/UZ4dHmcGooBSEshkjPYdo2qPAOJvgHoaVgZtIk2LxAbuKB2ojjAJRbgUoYWjNm KALU2S24p1iInSVDwKUK4yCYBD6aU/zB49sbj5TyK6O2Fh5iIIunHOcW16jS/J6w H8w/TWpJmjG0Fw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgedvgddufeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepvdehgfeivdejgedtveehfefhteelfefgieevgfffveefjeegtdfg uedthedtgeevnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.monjalon.net (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 17390108005B; Wed, 3 Feb 2021 15:02:24 -0500 (EST) From: Thomas Monjalon To: dev@dpdk.org Cc: Qi Zhang , Ferruh Yigit , Andrew Rybchenko Date: Wed, 3 Feb 2021 21:02:20 +0100 Message-Id: <20210203200220.3019205-1-thomas@monjalon.net> X-Mailer: git-send-email 2.30.0 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: 8bit Subject: [dpdk-dev] [PATCH v3 1/1] ethdev: refine doxygen comment of UDP tunnel API 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" From: Qi Zhang Clarify what is the scope and impact of the UDP port tunnel API. There are still missing infos to be improved in future: - no capability flag - dependency between ports of the same device - required privilege Signed-off-by: Qi Zhang Signed-off-by: Thomas Monjalon --- v2 (Qi): focus on API impact based on previous discussion v3 (Thomas): reword more lines, in functions, struct and enum --- lib/librte_ethdev/rte_ethdev.h | 57 ++++++++++++++++++++-------------- 1 file changed, 33 insertions(+), 24 deletions(-) diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h index 667373f06f..059a061072 100644 --- a/lib/librte_ethdev/rte_ethdev.h +++ b/lib/librte_ethdev/rte_ethdev.h @@ -1214,7 +1214,8 @@ struct rte_eth_pfc_conf { }; /** - * Tunneled type. + * Tunnel type for device-specific classifier configuration. + * @see rte_eth_udp_tunnel */ enum rte_eth_tunnel_type { RTE_TUNNEL_TYPE_NONE = 0, @@ -1270,14 +1271,16 @@ struct rte_fdir_conf { /** * UDP tunneling configuration. - * Used to config the UDP port for a type of tunnel. - * NICs need the UDP port to identify the tunnel type. - * Normally a type of tunnel has a default UDP port, this structure can be used - * in case if the users want to change or support more UDP port. + * + * Used to configure the classifier of a device, + * associating an UDP port with a type of tunnel. + * + * Some NICs may need such configuration to properly parse a tunnel + * with any standard or custom UDP port. */ struct rte_eth_udp_tunnel { uint16_t udp_port; /**< UDP port used for the tunnel. */ - uint8_t prot_type; /**< Tunnel type. Defined in rte_eth_tunnel_type. */ + uint8_t prot_type; /**< Tunnel type. @see rte_eth_tunnel_type */ }; /** @@ -3868,7 +3871,7 @@ int rte_eth_dev_rss_reta_update(uint16_t port_id, struct rte_eth_rss_reta_entry64 *reta_conf, uint16_t reta_size); - /** +/** * Query Redirection Table(RETA) of Receive Side Scaling of Ethernet device. * * @param port_id @@ -3890,7 +3893,7 @@ int rte_eth_dev_rss_reta_query(uint16_t port_id, struct rte_eth_rss_reta_entry64 *reta_conf, uint16_t reta_size); - /** +/** * Updates unicast hash table for receiving packet with the given destination * MAC address, and the packet is routed to all VFs for which the RX mode is * accept packets that match the unicast hash table. @@ -3912,7 +3915,7 @@ int rte_eth_dev_rss_reta_query(uint16_t port_id, int rte_eth_dev_uc_hash_table_set(uint16_t port_id, struct rte_ether_addr *addr, uint8_t on); - /** +/** * Updates all unicast hash bitmaps for receiving packet with any Unicast * Ethernet MAC addresses,the packet is routed to all VFs for which the RX * mode is accept packets that match the unicast hash table. @@ -3995,7 +3998,7 @@ int rte_eth_mirror_rule_reset(uint16_t port_id, int rte_eth_set_queue_rate_limit(uint16_t port_id, uint16_t queue_idx, uint16_t tx_rate); - /** +/** * Configuration of Receive Side Scaling hash computation of Ethernet device. * * @param port_id @@ -4012,7 +4015,7 @@ int rte_eth_set_queue_rate_limit(uint16_t port_id, uint16_t queue_idx, int rte_eth_dev_rss_hash_update(uint16_t port_id, struct rte_eth_rss_conf *rss_conf); - /** +/** * Retrieve current configuration of Receive Side Scaling hash computation * of Ethernet device. * @@ -4030,12 +4033,18 @@ int rte_eth_dev_rss_hash_conf_get(uint16_t port_id, struct rte_eth_rss_conf *rss_conf); - /** - * Add UDP tunneling port for a specific type of tunnel. - * The packets with this UDP port will be identified as this type of tunnel. - * Before enabling any offloading function for a tunnel, users can call this API - * 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. +/** + * Add UDP tunneling port for a type of tunnel. + * + * Some NICs may require such configuration to properly parse a tunnel + * with any standard or custom UDP port. + * The packets with this UDP port will be parsed for this type of tunnel. + * The device parser will also check the rest of the tunnel headers + * before classifying the packet. + * + * With some devices, this API will affect packet classification, i.e.: + * - mbuf.packet_type reported on Rx + * - rte_flow rules with tunnel items * * @param port_id * The port identifier of the Ethernet device. @@ -4052,13 +4061,13 @@ int rte_eth_dev_udp_tunnel_port_add(uint16_t port_id, struct rte_eth_udp_tunnel *tunnel_udp); - /** - * Delete UDP tunneling port a specific type of tunnel. - * The packets with this UDP port will not be identified as this type of tunnel - * any more. - * Before enabling any offloading function for a tunnel, users can call this API - * to delete a UDP port for the tunnel. So the offloading function will not take - * effect on the packets with the specific UDP port. +/** + * Delete UDP tunneling port for a type of tunnel. + * + * The packets with this UDP port will not be classified as this type of tunnel + * anymore if the device use such mapping for tunnel packet classification. + * + * @see rte_eth_dev_udp_tunnel_port_add * * @param port_id * The port identifier of the Ethernet device. -- 2.30.0