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 B9876A09FF; Mon, 11 Jan 2021 15:53:47 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 86466140E71; Mon, 11 Jan 2021 15:53:47 +0100 (CET) Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) by mails.dpdk.org (Postfix) with ESMTP id 1B259140E6D for ; Mon, 11 Jan 2021 15:53:46 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id DFB2D256B; Mon, 11 Jan 2021 09:53:43 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 11 Jan 2021 09:53:44 -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= Q4Pxxm3wqdtaVTd2+9hfBjZU1BjRVlkFsCDrBxbvCh4=; b=1ergVp+gjQ4PmlLj 0EDIfubqnNV7PPVoawpIM+4vYwLIeP8zd86thWeN5DYP8HfBmXydAUSwUrZB1nI2 An5VrjAoeg4JBzIulxZBnozwroFMZ4M0jUxeT7JsKW8N5nDspF+FUvpivcM0j8WO u5J3I/BU7t9yaM0vNdU20dTkZsS6jlBhqBQ9uvNEX4dUbUEV0Z+9RmixGLBg9Jsz IOYmnwVebJq8e0Q8flL+cG1ssf4E6ZM0sNum32eJNJcJrnVBTPMwbHX1Spbf2gSa Mcj8l7yRmT4faazgpfD4vCFixjUOgIdgBcnG2g46nRmU+0Q4aSB4DXPu3/5S4wZH Nay7bg== 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=Q4Pxxm3wqdtaVTd2+9hfBjZU1BjRVlkFsCDrBxbvC h4=; b=dOGJla5L4agAnVWhVdLLRFv6lzo/uuhnpI1ygwrxMyvWDRuE4/isRRXp+ 8+CQLjJ6rG4uT0ox/87vkEpWbpHyPSEzXkx14cQyrUx8C8tUtEGa32FMFUmvB/d8 VJ+Elyj5WqomGZjRLxEaLcppbmYT6Vg+BmHoXu9LnPasNczlyWo6nm8okZMbwwhY vNlyK5k0xjMJtAOlfjIiEZKaNbu6r8e2YLoRnog+P64bitVbmSItwax0qehxVOI5 3uOCUxNmxGbMyPmbxMLNa0tyzeY3VVC10EG2UnD60fU/kc3p2Vxmi38Ce3CihsI8 nd7OXZwrBqxJ0ns8qROBcYmhmgiGA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdehuddgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 85FF91080064; Mon, 11 Jan 2021 09:53:40 -0500 (EST) From: Thomas Monjalon To: "Yigit, Ferruh" , "Guo, Jia" , "Zhang, Qi Z" Cc: Andrew Rybchenko , Ori Kam , "Wu, Jingjing" , "Yang, Qiming" , "Wang, Haiyue" , "dev@dpdk.org" , Gregory Etelson , "maxime.coquelin@redhat.com" , "jerinj@marvell.com" , "ajit.khaparde@broadcom.com" , Bing Zhao Date: Mon, 11 Jan 2021 15:53:38 +0100 Message-ID: <7526138.hoSOgffrVm@thomas> In-Reply-To: References: <20201216085854.7842-1-jia.guo@intel.com> <9702007.LWHD5a8EkP@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri 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" 11/01/2021 15:02, Zhang, Qi Z: > From: Thomas Monjalon > > 11/01/2021 12:26, Zhang, Qi Z: > > > From: Thomas Monjalon > > > > 10/01/2021 11:46, Ori Kam: > > > > > From: Zhang, Qi Z > > > > > > From: Thomas Monjalon > > > > > > > 08/01/2021 10:29, Andrew Rybchenko: > > > > > > > > On 1/8/21 11:57 AM, Ferruh Yigit wrote: > > > > > > > > > On 1/8/2021 1:41 AM, Zhang, Qi Z wrote: > > > > > > > > >> From: Thomas Monjalon > > > > > > > > >>> Yes the port number is free. > > > > > > > > >>> But isn't it more natural to specify this port number as > > > > > > > > >>> part of the rte_flow rule? > > > > > > > > >> > > > > > > > > >> I think if we have a rte_flow action type that can be > > > > > > > > >> used to set a packet's tunnel type xxx, like below #flow > > > > > > > > >> create eth/ipv4/udp port is 4789/... action > > > > > > > > >> set_tunnel_type VxLAN / end then we may replace it with > > > > > > > > >> rte_flow, but I'm not sure if it's necessary, > > > > > > > > >> please share if you have a better idea. > > > > > > > > > > > > > > Of course we can specify the UDP port in rte_flow rule. > > > > > > > Please check rte_flow_item_udp. > > > > > > > That's a basic of rte_flow. > > > > > > > > > > > > Its not about the pattern match, it's about the action, what we > > > > > > need is a rte_flow action to "define a packet's tunnel type", but we don't > > have. > > > > > > > > A packet type alone is meaningless. > > > > It is always associated to an action, this is what rte_flow does. > > > > > > As I mentioned in previous, this is a device (port) level configuration, so it can > > only be configured by a PF driver or a privileged VF base on our security model. > > > A typical usage in a NFV environment could be: > > > > > > 1. A privileged VF (e.g. ice_dcf PMD) use rte_eth_dev_udp_tunnel_port_add > > to create tunnel port for eCPRI, them this will impact on all VFs in the same PF. > > > 2. A normal VF driver can create rte_flow rule that match specific patch for > > queue steering or apply RSS for eCPRI packets, but it DON'T have the > > permission to define the tunnel port. > > > > Whaooh! A normal Intel VF is not allowed to match the tunnel it wants if not > > enabled by a priviledged VF? > > > I would say it is a HW design flaw, but that's not the question. > > Why you think this is a design flaw? in real case, > is it a typical requirement that different VF > need different tunnel port for eCPRI (or VxLan) on the same PF? They are different VFs, so why should they use the same UDP port? Anyway it doesn't need to be typical to be allowed. > I believe it's not necessary to make it as a per VF resource > in most cases, and I will be surprise if a driver that > allow any VF to change the share resource without any privilege control. The thing is that a flow rule should not be a shared resource. In Intel devices, it seems the UDP port of a protocol is supposed to be shared with all VFs, but it looks a very specific assumption, or limitation. I wonder how we can document this and ask the user to call rte_eth_dev_udp_tunnel_port_add(), because of some devices. Anyway, this is currently poorly documented. > Btw I guess mlx NIC has more flexible way to handle ecpri tunnel, > just curious how it works, what's the expected result of below rules? > > 1. create flow eth / ipv4 / udp dst is 1234 / ecpri msgtype is 0 / ... to queue 0 > 2. create flow eth / ipv4 / udp dst is 5678 / ecrpi msgtype is 1 / ... to queue 1. It should move the eCPRI packets to the right queue, taking into consideration the UDP port and the message type. Of course there may be some bugs :) > So both 1234 and 5678 will be regarded as an ECPRI packet? Yes, both should be considered eCPRI. > Or only the first one will work? I am not aware of such limitation. > does dst udp port is always needed if an ecpri pattern is involved? No, the UDP part is optional.