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 665E3A04B5; Tue, 12 Jan 2021 03:14:14 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F1F1F140D97; Tue, 12 Jan 2021 03:14:12 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 56AB5140D8E for ; Tue, 12 Jan 2021 03:14:11 +0100 (CET) IronPort-SDR: SkNnWX3i8INxHTCB4RzChWndxX4Y4sbmITCDKx1xTzAu7ttGz1fe8/OnX4bXEMgpy9kHXsX69U zWulD5obGRMg== X-IronPort-AV: E=McAfee;i="6000,8403,9861"; a="178062466" X-IronPort-AV: E=Sophos;i="5.79,340,1602572400"; d="scan'208";a="178062466" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2021 18:14:10 -0800 IronPort-SDR: sT8YpZyIXF/JFcNg8NSZ9rM0AgCYOWuml3sfoPL1ayCRW5I3iX58X0/lddWV+6pKIdssn5+Xqo CGbcW5bC3x5g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,340,1602572400"; d="scan'208";a="397221747" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga004.fm.intel.com with ESMTP; 11 Jan 2021 18:14:09 -0800 Received: from shsmsx603.ccr.corp.intel.com (10.109.6.143) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 11 Jan 2021 18:14:09 -0800 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX603.ccr.corp.intel.com (10.109.6.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 12 Jan 2021 10:14:07 +0800 Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.1713.004; Tue, 12 Jan 2021 10:14:07 +0800 From: "Zhang, Qi Z" To: Thomas Monjalon , "Yigit, Ferruh" , "Guo, Jia" 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 Thread-Topic: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri Thread-Index: AQHW2cLnLDO52W/MnUi6XmgEhPhIWqoauFcAgAC+FICAAAryAIAAqDkQ//+QKICAAIuhsP//rcCAgAEHCvCAAATsgIAACNMAgAASpwCAAXQdcIABs1eAgAF7OwCAAI+HcP//lfKAABD1cDD//68RAP/+1Y+Q Date: Tue, 12 Jan 2021 02:14:07 +0000 Message-ID: <7ef7738be8304c42a69edc0b23e33a79@intel.com> References: <20201216085854.7842-1-jia.guo@intel.com> <9702007.LWHD5a8EkP@thomas> <7526138.hoSOgffrVm@thomas> In-Reply-To: <7526138.hoSOgffrVm@thomas> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.5.1.3 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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" > -----Original Message----- > From: Thomas Monjalon > Sent: Monday, January 11, 2021 10:54 PM > 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 > Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for= ecpri >=20 > 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 secu= rity > 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? >=20 > 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 cas= es 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 softwa= re flexibility but get a more simplified firmware and save more hardware re= source from unnecessary usage. >=20 > > 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. >=20 > 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 s= hared > 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. >=20 > > 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. >=20 > It should move the eCPRI packets to the right queue, taking into consider= ation > 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", =20 but this is not the question, I believe your answers are all fit for the Vx= Lan case :) For VxLAN offload I note below statement from your user manual *If you configure multiple UDP ports for offload and exceed the total numbe= r of ports supported by hardware, then those additional ports will still function properly, but will not benefit from any of the stateless off= loads.=20 Looks like you have a port limitation, additional port that above this numb= er 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 ge= neral flow table. The questions is how many is the limitation ? does each VF has its own res= ource pool?=20 If they are shared, how do you manage these ports?=20 What if one malicious VF used up all the tunnel ports, does another VF stil= l get chance to create its own? >=20 > > So both 1234 and 5678 will be regarded as an ECPRI packet? >=20 > Yes, both should be considered eCPRI. >=20 > > Or only the first one will work? >=20 > I am not aware of such limitation. >=20 > > does dst udp port is always needed if an ecpri pattern is involved? >=20 > No, the UDP part is optional. >=20