From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <jing.d.chen@intel.com> Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 9E300DD2 for <dev@dpdk.org>; Tue, 16 May 2017 02:54:25 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2017 17:54:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,346,1491289200"; d="scan'208";a="1130804336" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga001.jf.intel.com with ESMTP; 15 May 2017 17:54:24 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.18.124.200) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 15 May 2017 17:54:24 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX102.amr.corp.intel.com (10.18.124.200) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 15 May 2017 17:54:24 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.246]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.224]) with mapi id 14.03.0319.002; Tue, 16 May 2017 08:54:21 +0800 From: "Chen, Jing D" <jing.d.chen@intel.com> To: Thomas Monjalon <thomas@monjalon.net>, "Richardson, Bruce" <bruce.richardson@intel.com>, "Yigit, Ferruh" <ferruh.yigit@intel.com> CC: "dev@dpdk.org" <dev@dpdk.org>, Yuanhan Liu <yuanhan.liu@linux.intel.com>, Maxime Coquelin <maxime.coquelin@redhat.com>, "Zhang, Helin" <helin.zhang@intel.com>, "Wu, Jingjing" <jingjing.wu@intel.com>, "Lu, Wenzhuo" <wenzhuo.lu@intel.com>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com> Thread-Topic: SIMD Rx/Tx paths Thread-Index: AQHSzXfXpAL2MPSgXU+IZ7Nx3LgL7KH02YuAgAAF44CAAAodgIAAA9UAgAEyFZA= Date: Tue, 16 May 2017 00:54:21 +0000 Message-ID: <4341B239C0EFF9468EE453F9E9F4604D3C64A3E5@shsmsx102.ccr.corp.intel.com> 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: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Tue, 16 May 2017 00:54:27 -0000 > 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)? I also agree auto-selection on tx/rx func. User needn't worry about how PMD= to=20 satisfy its' requirement, result is more important.=20 Besides that, we should do more work in rx/tx configuration to help PMD bet= ter decide the best rx/tx. Pkt_type is a good example.=20 A possible way is to expose all possible PMD offload features into structur= e=20 rte_eth_rxmode and rte_eth_txmode or a new structure.