From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00076.outbound.protection.outlook.com [40.107.0.76]) by dpdk.org (Postfix) with ESMTP id 17EC71F5 for ; Tue, 16 May 2017 07:36:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6hp2B8mtPt5QvS1WA8O8m82W4XnU2Vc8MXnSx9Q6Ncw=; b=HKbWNJKomfH7eDKteXwZ63PY0CgeMhJ+BCGDWRFj4KE9ojVdjFZxePXLGpak6yVSAjHK02pcucS6VcoYLUJpp7GPRQbEYkwqN+o51THf7wMZmbOYmj4zctVo6OhNSK4N21Pieq0HaJLHjeXqFBTXC40Ck3kYVTE3kjrUBLnvjtY= Received: from AM4PR05MB1505.eurprd05.prod.outlook.com (10.164.79.147) by AM4PR05MB1507.eurprd05.prod.outlook.com (10.164.79.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Tue, 16 May 2017 05:36:23 +0000 Received: from AM4PR05MB1505.eurprd05.prod.outlook.com ([fe80::80f1:6d48:a372:7ebe]) by AM4PR05MB1505.eurprd05.prod.outlook.com ([fe80::80f1:6d48:a372:7ebe%14]) with mapi id 15.01.1084.027; Tue, 16 May 2017 05:36:23 +0000 From: Shahaf Shuler To: Thomas Monjalon , "Richardson, Bruce" , "Yigit, Ferruh" , Adrien Mazarguil CC: "dev@dpdk.org" , Yuanhan Liu , Maxime Coquelin , "Chen, Jing D" , "Zhang, Helin" , "Wu, Jingjing" , "Lu, Wenzhuo" , "Ananyev, Konstantin" Thread-Topic: [dpdk-dev] SIMD Rx/Tx paths Thread-Index: AQHSzYVXmmxbcoJFhkGXQDz48GHA86H1c2EAgAD8k/A= Date: Tue, 16 May 2017 05:36:22 +0000 Message-ID: References: <1857248.OtrprS2xZT@xps> <4a758068-a05e-4b67-0647-f3c57a32f23d@intel.com> <59AF69C657FD0841A61C55336867B5B066772FFA@IRSMSX104.ger.corp.intel.com> <4150352.hFenEnrka8@xps> In-Reply-To: <4150352.hFenEnrka8@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: monjalon.net; dkim=none (message not signed) header.d=none;monjalon.net; dmarc=none action=none header.from=mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR05MB1507; 7:0keFzIYXRLB4VnNIqeOEd9AfoECA7hjLv7e6KlzMZvggYUeYpNpcLSReMhZlNbHai1Arm+qDBEmwqtjOqZxp4JcDbQUKhxIUYQLS4BUTGWnsU/TQg6vRkgyUERcgrNWd8aBG38JKKSMRg/22VwO3El6s3PCBTFNEzHPualhSTXpYMe1/Mk4ShQYV1ozV63uobixgi9gwoYcy8X5TSy29gHFzZyoXi1LVuNR4fSTUbr62dqtfjRWFWnITQu/a7sfnWzIXDXjb8p4NZpZFwuXaANhiDdn6jC6EWzb/5WHSUCC/lVBaowG3/SBgmbBEMyToJXP1+6bCDiT2GA0bApx6sQ== x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-ms-office365-filtering-correlation-id: c45e4ff4-f775-4b40-f315-08d49c1d7cef x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM4PR05MB1507; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(6072148); SRVR:AM4PR05MB1507; BCL:0; PCL:0; RULEID:; SRVR:AM4PR05MB1507; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39860400002)(39410400002)(39400400002)(24454002)(377454003)(53936002)(6506006)(54356999)(50986999)(76176999)(966005)(74316002)(4326008)(54906002)(6306002)(8676002)(99286003)(55016002)(5250100002)(478600001)(6436002)(7696004)(9686003)(86362001)(5660300001)(81166006)(229853002)(2900100001)(53376002)(38730400002)(25786009)(53546009)(6246003)(8936002)(2950100002)(6116002)(3846002)(102836003)(2906002)(33656002)(3280700002)(7736002)(3660700001)(93886004)(66066001)(189998001)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR05MB1507; H:AM4PR05MB1505.eurprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2017 05:36:22.9356 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR05MB1507 Subject: Re: [dpdk-dev] SIMD Rx/Tx paths 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: , X-List-Received-Date: Tue, 16 May 2017 05:36:27 -0000 Monday, May 15, 2017 5:26 PM, Thomas Monjalon: > 15/05/2017 16:12, Richardson, Bruce: > > From: Yigit, Ferruh > > > On 5/15/2017 2:15 PM, Bruce Richardson wrote: > > > > On Mon, May 15, 2017 at 02:35:55PM +0200, Thomas Monjalon wrote: > > > >> Hi, > > > >> > > > >> I would like to open a discussion about SIMD code in drivers. > > > >> > > > >> I think we should not have different behaviours or features > > > >> capabilities, in the different code paths of a same driver. > > > >> I suggest to consider such differences as exceptions. > > > >> So we should merge features files (i.e. matrix columns), and > > > >> remove these files: > > > >> > > > >> % ls doc/guides/nics/features/*_vec.ini > > > >> > > > >> doc/guides/nics/features/fm10k_vec.ini > > > >> doc/guides/nics/features/fm10k_vf_vec.ini > > > >> doc/guides/nics/features/i40e_vec.ini > > > >> doc/guides/nics/features/i40e_vf_vec.ini > > > >> doc/guides/nics/features/ixgbe_vec.ini > > > >> doc/guides/nics/features/ixgbe_vf_vec.ini > > > >> doc/guides/nics/features/virtio_vec.ini > > > >> > > > >> If a feature is not supported in all code paths of a driver, it > > > >> must be marked as partially (P) supported. > > > >> > > > >> Then the mid-term goal will be to try removing these inconsistenci= es. > > > >> > > > >> Opinions/comments? > > > > > > > > Yes, there are inconsistencies, but if they are hidden from the > > > > user, e.g. by having the driver select automatically the most > > > > appropriate path, I don't think we should need to mark the support = as > "partial". > > > > Instead, it should be marked as being fully supported, but perhaps > > > > with a note indicating that a performance hit may be experienced > > > > due to the code taking a less-optimised driver path. After all, > > > > especially in the TX code path, a lot of the speed-up comes from > > > > not supporting different features, as well as from the > > > > vectorization. In those cases "closing the gap" may mean losing > > > > performance for those who don't want the features, which is not > > > > acceptable. Any feature support we can add, without affecting > performance, should of course be implemented. > > > > > > I mostly agree with Bruce, except for PMD selection the patch > > > automatically. > > > > > > There is a trade off between feature set and performance, scalar > > > driver favors features and vector driver favors performance, I think > > > good to have both. > > > > > > And I agree that feature support should be added to vector drivers > > > as long as it doesn't effect the performance. > > > > > > Related to the driver auto selecting the path, I concern this may > > > confuse the user, because he may end up a situation he doesn't clear > > > about supported features, I am for more explicit way to select the > > > scalar or vector driver. > > > > > > And for merging the features files, most of the items are already > > > same for scalar and vector drivers, so perhaps we can merge files > > > and use different syntax for features that is different for scalar an= d > vector: > > > Ys: Yes Scalar [no vector] > > > Yv: Yes Vector [no scalar] > > > Y: Yes Both > > > Ps: Partially Scalar [no vector] > > > Pv: Partially Vector [no scalar] > > > P: Partially Both > > > YsPv, YvPs >=20 > Please remember that there are different vector code paths (SSE/AVX, > NEON, Altivec). >=20 > > For the table, I don't really mind so much what scheme is agreed. For t= he > user doing the coding, while I can accept that it might be useful to supp= ort > explicitly request a vector or scalar driver, I'd definitely prefer the d= efault > state to remain auto-selection based on features requested. If a user wan= t > TSO, then pick the best driver path that supports TSO, and don't force th= e > user to read up on what the different paths are! >=20 > I agree. > If we can be sure what the application needs, we can select the best code > path and mark the feature supported. > But can we be sure of the expectations for every features? > How do we know that the application relies on certain packet types (which > are not recognized by some code paths)? This work might help for this [1]. The application will specify on device configuration which Tx and Rx offloa= ds it needs.=20 Knowing that each feature request might affect the performance, the applica= tion is expected to choose the most limited set of offloads.=20 The PMD, will then choose accordingly the best data path function which sup= ports all of those offloads, knowing the rest will never be used. [1] http://dpdk.org/ml/archives/dev/2017-May/065077.html