From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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" <qi.z.zhang@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
CC: "dev@dpdk.org" <dev@dpdk.org>, "Yigit, Ferruh" <ferruh.yigit@intel.com>,
 "orika@nvidia.com" <orika@nvidia.com>, "getelson@nvidia.com"
 <getelson@nvidia.com>, "andrew.rybchenko@oktetlabs.ru"
 <andrew.rybchenko@oktetlabs.ru>, "ajit.khaparde@broadcom.com"
 <ajit.khaparde@broadcom.com>, "jerinj@marvell.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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Thomas:
	Thanks for review, comment in line

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, January 15, 2021 11:52 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>; 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 <qi.z.zhang@intel.com>
> > ---
> > --- 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