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 A704DA0A03; Mon, 18 Jan 2021 05:01:14 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 87F68140D74; Mon, 18 Jan 2021 05:01:14 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id E6D65140D6C for ; Mon, 18 Jan 2021 05:01:12 +0100 (CET) IronPort-SDR: KbwUDZ1GqhTmFAtO6nfJi/kbMoMYXFeC3k4X7HwK0NMC6ZMc8QooJaGMKFs/FBaM05NkeAp9Dj dmnWprVXL8VA== X-IronPort-AV: E=McAfee;i="6000,8403,9867"; a="197448091" X-IronPort-AV: E=Sophos;i="5.79,355,1602572400"; d="scan'208";a="197448091" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jan 2021 20:01:11 -0800 IronPort-SDR: P4jXUv0kRFrQMRI2MTmUY3E58ACNvb+YOxhNKLL/6vxy2lPNQ2qlCefAMgQCgncCLgx3gSUi0j VWjNev9bzoYA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,355,1602572400"; d="scan'208";a="569076143" Received: from irsmsx601.ger.corp.intel.com ([163.33.146.7]) by orsmga005.jf.intel.com with ESMTP; 17 Jan 2021 20:01:10 -0800 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by irsmsx601.ger.corp.intel.com (163.33.146.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 18 Jan 2021 04:01:08 +0000 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; Mon, 18 Jan 2021 12:01:06 +0800 From: "Zhang, Qi Z" To: Thomas Monjalon CC: "dev@dpdk.org" , "Yigit, Ferruh" , "orika@nvidia.com" , "getelson@nvidia.com" , "andrew.rybchenko@oktetlabs.ru" , "ajit.khaparde@broadcom.com" , "jerinj@marvell.com" Thread-Topic: [dpdk-dev] [PATCH] ethdev: refine API description Thread-Index: AQHW6NgcJoMxlkFmOUi+LySLN4xRuaooVOIAgARUuyA= Date: Mon, 18 Jan 2021 04:01:06 +0000 Message-ID: <6f81345b4dc7435381a5ca4ea2fc420a@intel.com> References: <20210112114703.350878-1-qi.z.zhang@intel.com> <4389911.iuVQrazR7g@thomas> In-Reply-To: <4389911.iuVQrazR7g@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] [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 Thomas: Thanks for review, comment in line > -----Original Message----- > From: Thomas Monjalon > Sent: Friday, January 15, 2021 11:52 PM > To: Zhang, Qi Z > Cc: dev@dpdk.org; Yigit, Ferruh ; orika@nvidia.co= m; > getelson@nvidia.com; andrew.rybchenko@oktetlabs.ru; > ajit.khaparde@broadcom.com; jerinj@marvell.com > Subject: Re: [dpdk-dev] [PATCH] ethdev: refine API description >=20 > Hi, >=20 > It seems we need to clarify how the API for UDP tunnel works with rte_flo= w. > Thanks for starting this patch. > I ask some questions below for writing a clear and exact API definition. >=20 > 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. >=20 > I think this assumption is too vague to be useful. > It brings more confusion than it explains. OK, let's focus on the API impact as you suggested. >=20 > > + * > > + * 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 >=20 > What is a privileged VF exactly? Yes, looks like "a privileged VF" is not generic enough here, actually it s= hould be a driver that implement DPDK ethdev API and able to perform device= /port level configure,=20 for example use rte_flow to steer traffic to specific VF, configure UDP tun= nel port .... it is something like a "host driver" It could be a pure user pace DPDK PF driver, or a vdev / SR-IOV driver back= ended by a kernel driver but be granted to have privilege to access more d= evice resource through some sw/hw channel. >=20 > > + * other VFs. For the second case, a tunnel configure could be > > + embedded in a > > + * rte_flow rule. >=20 > I suggest we make the explanation more API-oriented. >=20 > First thing to explain: this API will have effect on rte_flow rules only,= am I right? I think it should not only impact the rte_flow, but also may impact the pac= ket type that extract from Rx Descriptor to mbuf on some devices Because without this configure, the parser is not able to recognize the spe= cific tunnel type >=20 > 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 Some driver may not allow to specific a tunnel port in rte_flow as rte_eth_= dev_udp_tunnel_port_add is prefer API to handle this. > 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? If a packet only have udp tunnel port but don't have tunnel header, so the = packet will still not be recognized as a an tunnel packet by the parser, th= e pattern is not matched and action A should not be executed. > 2/ [UDP Y] - no tunnel header > -> none (flow rule requires a tunnel header) Yes, expected result > 3/ [UDP X] [tunnel T] > -> A Yes, expected result > 4/ [UDP Y] [tunnel T] > -> B Yes, expected result, if the rule #2 is allowed to create > 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? Should be none. > 6/ [UDP Y] [tunnel U] > -> none Yes expected result. >=20 > Last question, how it plays with rte_flow_tunnel_match? > Should we replace rte_eth_udp_tunnel with rte_flow_tunnel_match? My understanding is rte_flow_tunnel_match is just a help function, it help = to generate a set of rte_flow_items to feed a new rule creation, so looks l= ike it is not expected to have any interaction with hardware? So I didn't f= igure out how can we use it to replace, But maybe we can introduce somethi= ng new like rte_flow_tunnel_create as we already have a rte_flow_tunnel str= ucture which looks more generic than the existing API that only take udp po= rt for tunnel configure. >=20