From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id C884820F for ; Tue, 16 May 2017 11:27:24 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2017 02:27:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,348,1491289200"; d="scan'208";a="102231259" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.42]) by fmsmga005.fm.intel.com with SMTP; 16 May 2017 02:27:19 -0700 Received: by (sSMTP sendmail emulation); Tue, 16 May 2017 10:27:18 +0100 Date: Tue, 16 May 2017 10:27:18 +0100 From: Bruce Richardson To: Shahaf Shuler Cc: Thomas Monjalon , "Yigit, Ferruh" , Adrien Mazarguil , "dev@dpdk.org" , Yuanhan Liu , Maxime Coquelin , "Chen, Jing D" , "Zhang, Helin" , "Wu, Jingjing" , "Lu, Wenzhuo" , "Ananyev, Konstantin" Message-ID: <20170516092718.GA808@bricha3-MOBL3.ger.corp.intel.com> References: <1857248.OtrprS2xZT@xps> <4a758068-a05e-4b67-0647-f3c57a32f23d@intel.com> <59AF69C657FD0841A61C55336867B5B066772FFA@IRSMSX104.ger.corp.intel.com> <4150352.hFenEnrka8@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.0 (2017-02-23) 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 09:27:25 -0000 On Tue, May 16, 2017 at 05:36:22AM +0000, Shahaf Shuler wrote: > 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 inconsistencies. > > > > >> > > > > >> 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 and > > 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 > > > > Please remember that there are different vector code paths (SSE/AVX, > > NEON, Altivec). > > > > > For the table, I don't really mind so much what scheme is agreed. For the > > user doing the coding, while I can accept that it might be useful to support > > explicitly request a vector or scalar driver, I'd definitely prefer the default > > state to remain auto-selection based on features requested. If a user want > > TSO, then pick the best driver path that supports TSO, and don't force the > > user to read up on what the different paths are! > > > > 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 offloads it needs. > Knowing that each feature request might affect the performance, the application is expected to choose the most limited set of offloads. > The PMD, will then choose accordingly the best data path function which supports all of those offloads, knowing the rest will never be used. > > [1] http://dpdk.org/ml/archives/dev/2017-May/065077.html > Agreed.