From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3902BA034F; Sat, 2 Nov 2019 20:21:18 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7FB771DFE5; Sat, 2 Nov 2019 20:21:17 +0100 (CET) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by dpdk.org (Postfix) with ESMTP id 608EB1DF94 for ; Sat, 2 Nov 2019 20:21:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5280; q=dns/txt; s=iport; t=1572722475; x=1573932075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0qruc1xqUxP/7I+CfIKWX9ln0owALGIyoRAvQtivevo=; b=hJMwvXSH75DELuc8gNxjKw3TOSTY9iDSjzzbnIXNRMYXBsNXZHlEsK6S DWj4eaxdANSSJtAKYjHSCigRirVObMQI9eTYEuEvVjCDSD/KXZhe15Ei1 zvBXCPTyBxooMkMguLznhuVjTRr65GebiJI6yMNszhnGMzxDOsVidqEau U=; IronPort-PHdr: =?us-ascii?q?9a23=3AWeV1GhzGVL3CnyfXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuJAEjyNv/taQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AABQ1r1d/4cNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgX2BSyQsBWxYIAQLKgqHZQOKdE6CEIl?= =?us-ascii?q?WjieBQoEQA1QJAQEBDAEBGxICAQGEQAKDeyQ4EwIDCwEBBAEBAQIBBQRthTc?= =?us-ascii?q?MhVEBAQEBAgESKAYBATcBBAcEAgEIDgMEAQEBHhAhER0IAgQOBRQHB4MAAYJ?= =?us-ascii?q?GAw4gAQOlegKBOIhggieCfgEBBYUUDQuCFwmBNowTGIFAP4ERJx+BTn4+ghu?= =?us-ascii?q?BdwESAR+DQoIsj0eGFpdYQQqCJIcRhR6Ed4QQG4I8h1qPT5kBjAGDFwIEAgQ?= =?us-ascii?q?FAg4BAQWBaSINWnFwFWUBgkEJNRIRFIMGDBeDUIJkhUmBUFZ0AYEnixWBIgG?= =?us-ascii?q?BDQEB?= X-IronPort-AV: E=Sophos;i="5.68,260,1569283200"; d="scan'208";a="658007185" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Nov 2019 19:21:13 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xA2JLD5A005328 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 2 Nov 2019 19:21:13 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 2 Nov 2019 14:21:12 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 2 Nov 2019 14:21:11 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 2 Nov 2019 14:21:11 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OZvOyeGHKRSzO+6we8aeV2ozbudhkGiUiNPlq75DVOcRMnOhZUG1XDNbCSSeuzWHEOKwEQxooim4TIB74/4+exkFsCz6axptKFwcVNaAWzUiRhdQSNmCtjTtwPhah83QL/YxLbn7zEGzs5YFWLieaQRfDR257Ba12hX5POlCkYHjMfwkRPJueYaBmdslTt8h6TJ2FyipsdAH0pdqhU7VOUIavoIuS3dT28aWCXCrAqZnP9BHJNEEPtxRmbhRqFL+VKzUiL+5iLck3XSBL96v/YjTGZIaGDUl5abXaC+YNe/diNBRWmKJQiSPjGhtd+9uDr4L0H6normwlajsBgF6lg== 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=dDD9OWCD0IpNRYmieTE7s2RuummDC/B8RHV/52VhrRg=; b=BvmEggUpaiR8XwHgwPVzA5YLpdBkrqJLcv6S6mn4Hk8SpcC8/RgIkn1NCPNiEXHYiBSIjcloD3JLhVtcvsPdQzh8SHno8y/YdyjwPG4HQjMCjAEfg/awf4GzlsXHv2BdJfctAEMnOJ00FF/in4qKVLNrEn+BDrabYdOEXE864wfFRmjeIDgVK8ickmlgGabgO3rto0QDIOa2UAwZXVFyH2ChjHLgKdlzJV/7h7N+FbN/xqh9rG+pclv63sTXU7gvhTRSBeonHd2WTviHyal33FIjw4ZFcfGGHV0dJ8gMFaS8ja9tlsfcPR8W0KUPFLq5yVmci6CE91p5zrk1MsqtDA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dDD9OWCD0IpNRYmieTE7s2RuummDC/B8RHV/52VhrRg=; b=I0AA+pnfkE4PjbO0R2Od71JZNVNKZrVCVbmtt1nbCEsNxcimw7aslAsvkpsftdAJ35PNDM4SnX0af9KjksJLVnI3LZCGEw6ODNpz8WQr+IdeNCpnxybuwwNRlTPftywWvuHr8+DVIqYON1QXBhPcwjyDVeV2/xa9/xvigoK41qg= Received: from DM5PR11MB1979.namprd11.prod.outlook.com (10.175.87.147) by DM5PR11MB1692.namprd11.prod.outlook.com (10.168.104.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.17; Sat, 2 Nov 2019 19:21:10 +0000 Received: from DM5PR11MB1979.namprd11.prod.outlook.com ([fe80::1f7:1e78:8f6e:b5af]) by DM5PR11MB1979.namprd11.prod.outlook.com ([fe80::1f7:1e78:8f6e:b5af%6]) with mapi id 15.20.2387.027; Sat, 2 Nov 2019 19:21:10 +0000 From: "Damjan Marion (damarion)" To: Slava Ovsiienko CC: "Liu, Yu Y" , "Wang, Haiyue" , Thomas Monjalon , "dev@dpdk.org" , "arybchenko@solarflare.com" , "Yigit, Ferruh" , "jerinjacobk@gmail.com" , "Ye, Xiaolong" , Ray Kinsella , "Sun, Chenmin" Thread-Topic: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information Thread-Index: AQHVkT6krHqtknl/+kySOROxuO4ejKd3a+QQgAAjd4CAALOEgA== Date: Sat, 2 Nov 2019 19:21:10 +0000 Message-ID: <56850BFA-ABD1-476D-9ED0-F599EBD6D1EE@cisco.com> References: <20191031171139.105110-1-haiyue.wang@intel.com> <20191031171139.105110-3-haiyue.wang@intel.com> <20693558.VL3dRorq05@xps> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3601.0.10) authentication-results: spf=none (sender IP is ) smtp.mailfrom=damarion@cisco.com; x-originating-ip: [141.136.135.145] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7bbf5a89-28ab-496f-1bb2-08d75fc9d18d x-ms-traffictypediagnostic: DM5PR11MB1692: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0209425D0A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(136003)(396003)(366004)(189003)(199004)(13464003)(6486002)(55236004)(186003)(305945005)(54906003)(316002)(478600001)(7736002)(8936002)(102836004)(45080400002)(7416002)(6506007)(50226002)(33656002)(14454004)(76176011)(66066001)(11346002)(486006)(446003)(2616005)(476003)(64756008)(6116002)(71200400001)(25786009)(26005)(6916009)(53546011)(14444005)(71190400001)(66476007)(2906002)(5660300002)(66556008)(76116006)(8676002)(81166006)(99286004)(81156014)(6512007)(6246003)(66946007)(66446008)(86362001)(3846002)(36756003)(91956017)(6436002)(4326008)(229853002)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1692; H:DM5PR11MB1979.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sad7jsZ9XRLAtE9qpC3qmF8/s4YlxfNHh8elbY/iA8jSjWm54rE9c/H680+njuW7sGZlFT0FO/Y8XgRfDbAPHtt6NbIDw+93m/qZLP6OvaicUZ4AOIEzKWp8v510sJeQFFGQ3C52YqO1vnZmXx967UwOiA+lOwai73NmmpPMpqy53KBDuKt5zMjggl0WPSKGx4VMM6osQfbhCxhjMBgAI/eeR3UXGgoBKLXlQ5wQGAjIAQXLU26PS8Swep0775JdEDnf1AjVLw+IvI46B5Ul9+RljP/130HhRx7d6qdanRDM+MBpTiZpFgY9AMlPq2BeqQ36G5HH0liofZmyISfHUTY8d2iyXpao0LcEYqRbjco+HaDlW3Y7VB8+cRqXIIfUJSCAG5DqQOBbjUqk2ysWKNUsRC5W838hFWZizUEGXOmMpyb0c9uCDdqrhoGfQwO+ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <4FFA8856E95A4A4C8DC2462BC4CF9E93@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7bbf5a89-28ab-496f-1bb2-08d75fc9d18d X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2019 19:21:10.1237 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: f/L9PDoG3OazOvizkNB8w0WvTKA98zm7LayzIE4SA4Y/NvQqCFFDxtHhyGzi7lTqz2AyGovBWXcb4PvNEa4Y4A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1692 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-2.cisco.com Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > On 2 Nov 2019, at 09:38, Slava Ovsiienko wrote= : >=20 > Hi >> -----Original Message----- >> From: Liu, Yu Y >> Sent: Saturday, November 2, 2019 8:56 >> To: Wang, Haiyue ; Thomas Monjalon >> >> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh >> ; jerinjacobk@gmail.com; Ye, Xiaolong >> ; Kinsella, Ray ; Sun, >> Chenmin ; Slava Ovsiienko >> ; Damjan Marion (damarion) >> ; Liu, Yu Y >> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mo= de >> information >>=20 >> Add Damjan from FD.io for awareness... >>=20 >> Hi Thomas, >>=20 >> Long time no see. Sorry I use outlook which is not friendly to community >> email. >>=20 >>> Anyway I will propose to replace this API in the next release. >> Will your plan be affected by API/ABI stable plan? >> BTW, if you propose new change in next release, it will make DPDK >> consumer(FD.io) to change again. >> So even if it is not affected to the API/ABI stable plan, do we still ha= ve time >> to get a solution for everyone in DPDK 19.11 with your >> contribution/acceleration? >>=20 >>> I suspect a real hidden issue in Intel CPUs that you try to mitigate. >> Please be rest assured it is not the case. >> This request is just from one FD.io project internal bug " tx/rx burst f= unction >> is shown as nil" reported by Chenmin. >=20 > Why just the presenting string with function name (possible with suffix) = is not enough? > I would like to see this API (strings approach) in mlx5 either, dropping= the entire feature > does not look nice, as for me. >=20 > We could consider some requirements for the name suffices to distinguish = whether > function uses vector instructions and which ones if any. >=20 >> My understanding is DPDK behavior was taken as bug for someone in FD.io >> project and potentially will mislead other DPDK consumer. >=20 > Why does FD.io code want to know which vector extension is used by burst = routines? > Is it going to share/preserve some resources (registers, etc.)? Is it rob= ust ? > Burst routines might not know whether vector extensions is used (they mig= ht call=20 > libraries, even rte_memcpy() can use vectors in implicit fashion). This is jut debug CLI print, it was added by me as a result of frustration = of dealing constantly with operational issues where people are reporting lower performance caused by D= PDK deciding for variety of reasons to switch from vector PMD to scalar one. >=20 >> Haiyue is working with Chenmin to address the issue and with your suppor= t it >> will be even better. >>=20 >> Your support will be highly appreciated! >>=20 >> Thanks & Regards, >> Yu Liu >>=20 >> -----Original Message----- >> From: dev On Behalf Of Wang, Haiyue >> Sent: Saturday, November 2, 2019 1:30 PM >> To: Thomas Monjalon >> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh >> ; jerinjacobk@gmail.com; Ye, Xiaolong >> ; Kinsella, Ray ; Sun, >> Chenmin ; Slava Ovsiienko >> >> Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getti= ng >> burst mode information >>=20 >>> -----Original Message----- >>> From: Thomas Monjalon >>> Sent: Saturday, November 2, 2019 06:46 >>> To: Wang, Haiyue >>> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh >>> ; jerinjacobk@gmail.com; Ye, Xiaolong >>> ; Kinsella, Ray ; Sun, >>> Chenmin ; Slava Ovsiienko >>> >>> Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst >>> mode information >>>=20 >>> Thank you for trying to address comments done late. >>>=20 >>> 31/10/2019 18:11, Haiyue Wang: >>>> --- a/lib/librte_ethdev/rte_ethdev.h >>>> +++ b/lib/librte_ethdev/rte_ethdev.h >>=20 >>=20 >>>> +#define RTE_ETH_BURST_ALTIVEC (1ULL << 2) >>>> +#define RTE_ETH_BURST_NEON (1ULL << 3) >>>> +#define RTE_ETH_BURST_SSE (1ULL << 4) >>>> +#define RTE_ETH_BURST_AVX2 (1ULL << 5) >>>> +#define RTE_ETH_BURST_AVX512 (1ULL << 6) >>>=20 >>> Of course, I still believe that giving a special treatment to vector >>> instructions is wrong. >>> You did not justify why it needs to be defined in bits instead of >>> string. I am not asking again because anyway you don't really reply. I >>> think you are executing an order you received and I don't want to >>> blame you more. >>> I suspect a real hidden issue in Intel CPUs that you try to mitigate. >>> No need to reply to this comment. >>> Anyway I will propose to replace this API in the next release. >>=20 >> Never mind, if this design is truly ugly, drop it all now. I also prefer= to do the >> best, that's why open source is amazing, thanks! ;-) >=20