From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id AE53DA32A8
	for <public@inbox.dpdk.org>; Sat, 26 Oct 2019 08:40:48 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 04CFA1BFD5;
	Sat, 26 Oct 2019 08:40:47 +0200 (CEST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com
 (mail-eopbgr150071.outbound.protection.outlook.com [40.107.15.71])
 by dpdk.org (Postfix) with ESMTP id 2FF0E1BF80
 for <dev@dpdk.org>; Sat, 26 Oct 2019 08:40:45 +0200 (CEST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=hIj6kIloixQhqyx/pX1bcRzZC2I5IfcMgLQN7yzaCU2ZUIaB/yGRW+U1U2EHZ99uiYjpF7RaAUccQbFwye09D3jESKiRYZiePZJzkg8qs/jsHkBeJHPh7CPTn1dmbLQlbmM6z1fcFX6SO3enyWLCHDy2SXZihO6IxKaOrbKOEkJm029RFMka7m/nu5nRM6ibTWBmb8HoVZXIDVqWqWoTEcpXD7L/i93vknfM5c6Yzt963XU8h4DAgjjZHA5RD+acEmIcTGt2+7InjqFPZ30TRc9iDE2OP1yfp2DK+f552dMDZRx5lPhaoWBZNb299lSKNk/IbnljIlvxx1zV3/cCsQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4X/aI+ewlvjBQKF6crCSb2iVFxtwy+nZfpXXZ2m2OLw=;
 b=azjITYijMnlRXXTkC9d7040OATsogBfWzu8sZCWzVTyEednmvSN3Q776VbmY1WxC8qyLtnykxRodmgM5AIvN0jR6fUzyeWQezHTViScUZOLLC3uvcld+lUMKTZ1KqQ9gSCi+AX6nZSaIlhHV+ttfSk4sf/wa+d57CbMJGba/+bNCw5GY39XzX382kkS1pjcnOPoCtfJsx/Z4ffjwoo3K4MncJ6xhDaWc2pntV/0QC2+SFsLv+UCbSfMehebHJCMBK2G4Aqrs8MCWGpZzAtJ2h5Oe/oVYOOJPFS2SEnV075bJQ7gsgsMqQuT/xeN1SGApmJNsLPgowMXB2y3LgzDVIQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com;
 dkim=pass header.d=mellanox.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4X/aI+ewlvjBQKF6crCSb2iVFxtwy+nZfpXXZ2m2OLw=;
 b=VYRZPjmTH4/pgA7DLyGyhDcMvHOpy3V/yEch7b8DIa5CHPiq/RLwi2uM12Gtf7uAHts8BW09aW0GYxYiKrfEYBBRdCMNkyEtfhBrZChDfLmWwbyda0dpFW0Q6nbHDojiZB/o0BuD+TuM9AZFNAvo6OQ1AYxHzt43pXW/0ViIzqs=
Received: from AM4PR05MB3265.eurprd05.prod.outlook.com (10.171.188.154) by
 AM4PR05MB3329.eurprd05.prod.outlook.com (10.171.189.33) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2387.20; Sat, 26 Oct 2019 06:40:43 +0000
Received: from AM4PR05MB3265.eurprd05.prod.outlook.com
 ([fe80::edab:529f:d14e:d3b]) by AM4PR05MB3265.eurprd05.prod.outlook.com
 ([fe80::edab:529f:d14e:d3b%7]) with mapi id 15.20.2387.025; Sat, 26 Oct 2019
 06:40:43 +0000
From: Slava Ovsiienko <viacheslavo@mellanox.com>
To: Thomas Monjalon <thomas@monjalon.net>, Jerin Jacob <jerinjacobk@gmail.com>
CC: Ferruh Yigit <ferruh.yigit@intel.com>, Haiyue Wang
 <haiyue.wang@intel.com>, dpdk-dev <dev@dpdk.org>, "xiaolong.ye@intel.com"
 <xiaolong.ye@intel.com>, "ray.kinsella@intel.com" <ray.kinsella@intel.com>,
 Bernard Iremonger <bernard.iremonger@intel.com>, "chenmin.sun@intel.com"
 <chenmin.sun@intel.com>, Andrew Rybchenko <arybchenko@solarflare.com>,
 Stephen Hemminger <stephen@networkplumber.org>, David Marchand
 <david.marchand@redhat.com>, Jerin Jacob <jerinj@marvell.com>
Thread-Topic: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst
 mode information
Thread-Index: AQHVixe7rVVmfhBjAUyys9nK8Rw9zKdrZUYAgAAf+U+AAGtMAIAAiDhQ
Date: Sat, 26 Oct 2019 06:40:43 +0000
Message-ID: <AM4PR05MB32650D8404170C77D717EC13D2640@AM4PR05MB3265.eurprd05.prod.outlook.com>
References: <20191015075133.38560-1-haiyue.wang@intel.com>
 <1811898.7XjjD7ZjLQ@xps>
 <CALBAE1MMo5oQPR9z5b1DszPuNe4UHjXM7B8PsJojJzJp6VFt-g@mail.gmail.com>
 <12001140.UMXFOKstgs@xps>
In-Reply-To: <12001140.UMXFOKstgs@xps>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=viacheslavo@mellanox.com; 
x-originating-ip: [95.164.10.10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 791a9cc7-07cc-48e8-9455-08d759df6d07
x-ms-traffictypediagnostic: AM4PR05MB3329:
x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr
x-microsoft-antispam-prvs: <AM4PR05MB33290AE45F18F75057E552C9D2640@AM4PR05MB3329.eurprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0202D21D2F
x-forefront-antispam-report: SFV:NSPM;
 SFS:(10009020)(4636009)(39860400002)(366004)(136003)(376002)(346002)(396003)(13464003)(189003)(199004)(25786009)(76176011)(7696005)(7416002)(446003)(6436002)(99286004)(478600001)(8936002)(71190400001)(14444005)(256004)(66066001)(2906002)(55016002)(9686003)(76116006)(66446008)(66556008)(81166006)(81156014)(486006)(8676002)(6116002)(66476007)(26005)(3846002)(229853002)(33656002)(11346002)(476003)(66946007)(6506007)(64756008)(52536014)(14454004)(53546011)(4326008)(86362001)(5660300002)(71200400001)(54906003)(6246003)(74316002)(305945005)(7736002)(316002)(102836004)(186003)(110136005);
 DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR05MB3329;
 H:AM4PR05MB3265.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en;
 PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: mellanox.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: kUlA3q0r0qCtsdk8oTu0dVfcgmwh0lowy7X1U9PiIbmTVBbZ/Mnyi6QEJeJFdqMnzpJeum2ax5520rqxixRDvMn8pqkicBoQHJi2ZtIqd+tlfEZNIaKzaNmZ8bKUbpjT6FTa92P8I9wPCRc7USTDH0Mc749F2b2296n+kfp0eszfaMrkIPIEVthtG690FJKtwv3hjq3JkUwvt0Wj4L6gfUaT9VH1Yd+w/d2E6yMduq8wzOTj+1BJ6/KKVXbsIsBPjq6RY+rWmA3+R+TTJJKNcAxCMXWn01X+oeTNy7d/t1F5HO0RZWkLXm/o+DZ71xJaXXr0bYbJSZpuOOYGVbCeiQtti7VDqlEO2RldXSD3YBwbO2Qg0Gpddk5HF9V75WzLe1cxB2Bye0JyFjjWNgWLpGQvPym+GJDJcSGQbIWbTOdD+YKVOr/J01jUKD6JLCSP
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Mellanox.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 791a9cc7-07cc-48e8-9455-08d759df6d07
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2019 06:40:43.6677 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 08qdichn7dtOrWkpTiWwjd+o8BNIRj2y9MWUnn6Pq/8MJeWUPfAFxBJANPLBICfJxHOjUwKCNVXiXw9KQiowXKfJ5YR867ukvu9QNngxzuc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR05MB3329
Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst
 mode information
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
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>



> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Saturday, October 26, 2019 1:27
> To: Jerin Jacob <jerinjacobk@gmail.com>
> Cc: Ferruh Yigit <ferruh.yigit@intel.com>; Haiyue Wang
> <haiyue.wang@intel.com>; dpdk-dev <dev@dpdk.org>;
> xiaolong.ye@intel.com; ray.kinsella@intel.com; Bernard Iremonger
> <bernard.iremonger@intel.com>; chenmin.sun@intel.com; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko
> <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand
> <david.marchand@redhat.com>; Jerin Jacob <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting bu=
rst
> mode information
>=20
> 25/10/2019 18:02, Jerin Jacob:
> > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon
> <thomas@monjalon.net> wrote:
> > > 25/10/2019 16:08, Ferruh Yigit:
> > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev
> > > > >> API that allows an application to retrieve the mode information
> > > > >> about Rx/Tx packet burst such as Scalar or Vector, and Vector
> > > > >> technology like AVX2.
> > > > >
> > > > > I missed this patch. I and Andrew, maintainers of ethdev, were no=
t
> CC'ed.
> > > > > Ferruh, I would expect to be Cc'ed and/or get a notification befo=
re
> merging.
> > > >
> > > > It has been discussed in the mail list and went through multiple
> > > > discussions, patch is out since the August, +1 to cc all
> > > > maintainers I missed that part, but when the patch is reviewed and
> there is no objection, why block the merge?
> > >
> > > I'm not saying blocking the merge.
> > > My bad is that I missed the patch and I am asking for help with a
> > > notification in this case. Same for Andrew I guess.
> > > Note: it is merged in master and I am looking to improve this feature=
.
> >
> > > > >> +/**
> > > > >> + * Ethernet device RX/TX queue packet burst mode information
> structure.
> > > > >> + * Used to retrieve information about packet burst mode setting=
.
> > > > >> + */
> > > > >> +struct rte_eth_burst_mode {
> > > > >> +  uint64_t options;
> > > > >> +};
> > > > >
> > > > > Why a struct for an integer?
> > > >
> > > > Again by a request from me, to not need to break the API if we
> > > > need to add more thing in the future.
> > >
> > > I would replace it with a string. This is the most flexible API.
> >
> > IMO, Probably, best of both worlds make a good option here, as Haiyue
> > suggested if we have an additional dev_specific[1] in structure.
> > and when a pass to the application, let common code make final string
> > as (options flags to string + dev_specific)
> >
> > options flag can be zero if PMD does not have any generic flags nor
> > interested in such a scheme.
> > Generic flags will help at least to have some common code.
> >
> > [1]
> > struct rte_eth_burst_mode {
> >         uint64_t options;
> >         char dev_specific[128]; /* PMD has specific burst mode
> > information */ };
>=20
> I really don't see how we can have generic flags.
> The flags which are proposed are just matching the functions implemented =
in
> Intel PMDs.
> And this is a complicate solution.
> Why not just returning a name for the selected Rx/Tx mode?
>=20
+1
Just an example, mlx5 PMD now has  approx. 60 tx_burst routines and most of=
 these ones
are not related to vectorized variations (but to tx offloads). Returning  t=
he name would be more
flexible and informative.=20

It is very common case to ask customer about which tx routine is engaged wi=
th particular settings,
now we have to ask to build the debug version and present the log.

With best regards, Slava