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 1D69BA0A03; Mon, 18 Jan 2021 10:49:47 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AD591140D13; Mon, 18 Jan 2021 10:49:46 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 6CAFB140D0F for ; Mon, 18 Jan 2021 10:49:45 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B36705C0125; Mon, 18 Jan 2021 04:49:43 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 18 Jan 2021 04:49:43 -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= HusGB0alqoUyWJJl2Dk54QplnhXSMgXkk3otoaHLpmI=; b=l5G4D11DYX/0eCHI 2xLAy70jDYoEVDFo6uSqt9QAzbtVz7tobgRV7YnLnQsMypiWn2t7/jZ1H3WVybWU jHRBtoH397pqnVLvI4V1QGVkbgw37GkZbmKUqwwxK6l0VTBRb/dNE9CH7JPXZ0tm JXH8XOJlGBayKZ+8XCcMN7DKoxVJ16Jphl3+u/tkFAS6EuBvVTanXHohEqqUzZsH kLp3l2wgJYqqPqHGN5vP730BiYebfILiBJNXBl+aNJis0sADOmHsXk14YLg8zdQw Ts17/u+1Eg8mJtkRl8St7VCO4DwTyf+0h+XshmiudLg+h+Zqax3mbCikv2viiw7K DhO6/g== 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=HusGB0alqoUyWJJl2Dk54QplnhXSMgXkk3otoaHLp mI=; b=cMKsLdrtYZUzjMr74c4863S3b5R3atBwJ6CWY1fFxBBbuqwMP7tkxepp7 FnSFOIk9l85uI2C3Rgd8QBqKjr/JOvGVbb3tVVMHarMCvcP6OeycFWtlDe/loxA1 jLmaDRUgBRjRNirBZAvDKx4xxv0A1qgoD0h68CgyJnsTxCGUnTOpnxpYoEWeooly /LGAFuRS/5VKYeeL/p28v6zll7/cOkDUxbdwT79sliiZ95mHy57O0+CQHn1d94o1 CqgG9qMyerqAaad0Gk3+hmRb0M3wEEKc9Qb72pU3NWfJWxSE6IAB0/AelN44apkj YKbWWPV8z0hpCCLUkDxxBUjXj45FQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtdekgddtlecutefuodetggdotefrodftvf 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 2C338108005C; Mon, 18 Jan 2021 04:49:42 -0500 (EST) From: Thomas Monjalon To: "Zhang, Qi Z" Cc: "dev@dpdk.org" , "Yigit, Ferruh" , "orika@nvidia.com" , "getelson@nvidia.com" , "andrew.rybchenko@oktetlabs.ru" , "ajit.khaparde@broadcom.com" , "jerinj@marvell.com" Date: Mon, 18 Jan 2021 10:49:40 +0100 Message-ID: <34434931.WU2RnIx0tX@thomas> In-Reply-To: <6f81345b4dc7435381a5ca4ea2fc420a@intel.com> References: <20210112114703.350878-1-qi.z.zhang@intel.com> <4389911.iuVQrazR7g@thomas> <6f81345b4dc7435381a5ca4ea2fc420a@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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 perform 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. How such device is granted privilege? > > > + * 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 only, 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 Oh right. This impact on mbuf classification should be part of the doxygen explanation. > > 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. Every rte_flow items and actions have limitations in drivers, that's OK. > > 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. OK I like it. Please make this behaviour clear in the doxygen. > > 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 Yes of course, if the rule cannot be created, the driver will reject it with an appropriate error code and a log mentioning the limitation. > > 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. OK makes sense. > > 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 help to generate a set of rte_flow_items to feed a new rule creation, so looks like it is not expected to have any interaction with hardware? So I didn't figure out 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 which looks more generic than the existing API that only take udp port for tunnel configure. Yes we need to think about it for future more generic API. Ori, any thoughts?