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 5CDBBA0A04; Fri, 15 Jan 2021 16:15:21 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 38592141130; Fri, 15 Jan 2021 16:15:21 +0100 (CET) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by mails.dpdk.org (Postfix) with ESMTP id 6DF7914112F for ; Fri, 15 Jan 2021 16:15:20 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 12DDA58094B; Fri, 15 Jan 2021 10:15:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 15 Jan 2021 10:15:19 -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= 8mDHnsAPJvjUETOGVZEutU7gBYOwXal0hAVxnHlhXIE=; b=KHjDLPKBur/TEgHv fXHiQKIxddJNuKTs+doVVd6HzMQ5wkZPDnxwQtjN6YQ1beKra7Tvjm3w0yHZzbtd j0iihxrrw7xNd69NZJ5ny9JGpOIpKkFZl05MBOmjOBzOXqcSq4aA6eaHwwon8NRY 6O63aBxNt9Sjo7W9f/m1TwW7HJjtczilaR5+R9Vs+OE61jiGPar4C90TSklGM/K7 hOJ9hqu67ManMuYCzrRPyTY/MXpu8iVIh5sgW3ccG9HMMjmbPt9b9i3zsH0cFknp 3ZfRVz0tOQuTkr0cSuq4vsfMxwIpWPbqyNHbhIR8gsNuBJSqG1gryfPJAvmPqFoN LggCfg== 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=8mDHnsAPJvjUETOGVZEutU7gBYOwXal0hAVxnHlhX IE=; b=fCvEBh9BCDRqLRagsVhhzHnK5DpsNUjuiUG7HT+Gn9kcAYdyxt/TMIvlD iGrEx7m5/1YHdJM9e0uWV4izBl+FDlzYEAawqqSEbLZx3iyFHvNtxpyY/uK7lNrd /rWund1J/2C/ddZvKwHBxJ/w9gKU0NI/XrB1xEDzeQ2KpcgjFpkgn02l+BT91b4u Hetsaq5ziKFIQwtLb2TY+7jXrZ465VCldjtGz77v9cGpe8iBKv216PaZcEzW/tr1 GuChyOSIFUyhzeZZnOsHzzb2d5ZRKztjfamPk/GlJfs69kJEXUD7g1SCNC/Wd4YC 7LLE2TwRigw2EXRPOAqBjrHr8hQ2A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtddvgdehtdcutefuodetggdotefrodftvf 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 63C40240062; Fri, 15 Jan 2021 10:15:16 -0500 (EST) From: Thomas Monjalon To: "Yigit, Ferruh" , "Guo, Jia" , "Zhang, Qi Z" Cc: dev@dpdk.org, 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: Fri, 15 Jan 2021 16:15:15 +0100 Message-ID: <1865276.fGLmMQUtVj@thomas> In-Reply-To: <7ef7738be8304c42a69edc0b23e33a79@intel.com> References: <20201216085854.7842-1-jia.guo@intel.com> <7526138.hoSOgffrVm@thomas> <7ef7738be8304c42a69edc0b23e33a79@intel.com> 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" 12/01/2021 03:14, Zhang, Qi Z: > From: Thomas Monjalon > > 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. > > Yes, of cause, your can support different UDP tunnel port for different VF, but there are lots of alternative ways to isolate VFs, its just not a big deal for most real use case. > The typical requirement is some customer want eCPRI with UDP port A, while another one want UDP port B, and our NIC is good enough to support both cases separately. > There are seldom cases that different eCPRI tunnel port need to be deployed on the same NIC or same port. > so from my view, it's a reasonable design compromise that lose minor software flexibility but get a more simplified firmware and save more hardware resource from unnecessary usage. > > > > > > 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. > > OK, let me check the document to see if anything we can improve. Thank you for trying to improve the doc. > > > 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 :) > > I guess it is not just some bugs, I saw below note in Mellanox latest MLX5 driver. > "eCPRI over UDP layer is not yet supported right now", > but this is not the question, I believe your answers are all fit for the VxLan case :) > > For VxLAN offload I note below statement from your user manual > > *If you configure multiple UDP ports for offload and exceed the total number of ports supported by hardware, then those additional ports will > still function properly, but will not benefit from any of the stateless offloads. > > Looks like you have a port limitation, additional port that above this number will not work with offload like RSS/steering ...,that's fine. > So my understanding the port resource is not just a regular rule in your general flow table. > The questions is how many is the limitation ? does each VF has its own resource pool? > If they are shared, how do you manage these ports? > What if one malicious VF used up all the tunnel ports, does another VF still get chance to create its own? Sorry I don't know exactly what are the limitations. >From DPDK point of view, when a flow rule cannot be created, it returns an error and the app must handle. Yes the app must handle limitations because there is no magic with hardware offloads: hardware are all more or less limited, that's a sad truth of our finite world ;)