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 0AB51A0A03; Tue, 19 Jan 2021 01:48:02 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BB902140D2C; Tue, 19 Jan 2021 01:48:01 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 49514140D2B for ; Tue, 19 Jan 2021 01:48:00 +0100 (CET) IronPort-SDR: k62g0dUEKAfLSXz+cgZXDFVF72B79un1sK7ZIb7X8IgKmcb/2Zdylg7g5w1zMjpx3tfKS+Y3Zc D2TqmAuLlwlQ== X-IronPort-AV: E=McAfee;i="6000,8403,9868"; a="178083463" X-IronPort-AV: E=Sophos;i="5.79,357,1602572400"; d="scan'208";a="178083463" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jan 2021 16:47:58 -0800 IronPort-SDR: IoCbFswkzp0k7MPtZlQG/40lmURMhxgaDE8Ml7F7MOgQwzxceFIvfl4GacwV3HwDvf8Ph+6nkO GA/G5keg1MGA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,357,1602572400"; d="scan'208";a="466501334" Received: from irsmsx604.ger.corp.intel.com ([163.33.146.137]) by fmsmga001.fm.intel.com with ESMTP; 18 Jan 2021 16:47:57 -0800 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by IRSMSX604.ger.corp.intel.com (163.33.146.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 19 Jan 2021 00:47:55 +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; Tue, 19 Jan 2021 08:47:53 +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+LySLN4xRuaooVOIAgARUuyD///0RAIAAwpTQ Date: Tue, 19 Jan 2021 00:47:53 +0000 Message-ID: <050b40a9e52445709c4ecb2786ccfbdb@intel.com> References: <20210112114703.350878-1-qi.z.zhang@intel.com> <4389911.iuVQrazR7g@thomas> <6f81345b4dc7435381a5ca4ea2fc420a@intel.com> <34434931.WU2RnIx0tX@thomas> In-Reply-To: <34434931.WU2RnIx0tX@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" > -----Original Message----- > From: Thomas Monjalon > Sent: Monday, January 18, 2021 5:50 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 > 18/01/2021 05:01, Zhang, Qi Z: > > From: Thomas Monjalon > > > 12/01/2021 12:47, Qi Zhang: > > > > + * 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 > > > > > > What is a privileged VF exactly? > > > > Yes, looks like "a privileged VF" is not generic enough here, actually > > it should be a driver that implement DPDK ethdev API and able to perfor= m > device/port level configure, for example use rte_flow to steer traffic to= specific > VF, configure UDP tunnel 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 = device > resource through some sw/hw channel. >=20 > How such device is granted privilege? There is no unified way currently as I know, but typically it should be con= figured from the host by an administrator through tools like ip / devlink .= .. >=20 >=20 > > > > + * other VFs. For the second case, a tunnel configure could be > > > > + embedded in a > > > > + * rte_flow rule. > > > > > > I suggest we make the explanation more API-oriented. > > > > > > First thing to explain: this API will have effect on rte_flow rules o= nly, am I > right? > > > > I think it should not only impact the rte_flow, but also may impact > > the packet type that extract from Rx Descriptor to mbuf on some > > devices Because without this configure, the parser is not able to > > recognize the specific tunnel type >=20 > Oh right. > This impact on mbuf classification should be part of the doxygen explanat= ion. >=20 >=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. >=20 > Every rte_flow items and actions have limitations in drivers, that's OK. >=20 > > > 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, = the pattern > is not matched and action A should not be executed. >=20 > OK I like it. Please make this behaviour clear in the doxygen. >=20 >=20 > > > 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 >=20 > Yes of course, if the rule cannot be created, the driver will reject it w= ith an > appropriate error code and a log mentioning the limitation. >=20 > > > 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. >=20 > OK makes sense. >=20 > > > 6/ [UDP Y] [tunnel U] > > > -> none > > > > Yes expected result. > > > > > > 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 h= elp to > generate a set of rte_flow_items to feed a new rule creation, so looks li= ke it is > not expected to have any interaction with hardware? So I didn't figure ou= t how > can we use it to replace, But maybe we can introduce something new like > rte_flow_tunnel_create as we already have a rte_flow_tunnel structure whi= ch > looks more generic than the existing API that only take udp port for tunn= el > configure. >=20 > Yes we need to think about it for future more generic API. > Ori, any thoughts? >=20