From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id A947D968 for ; Mon, 15 May 2017 16:26:18 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 04E6420A21; Mon, 15 May 2017 10:26:18 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 15 May 2017 10:26:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=ragREBJBEMxlnzz 0T1eitnGFt9b3zovUPd/B2F46z5E=; b=abvRFwWIoVfYzDYz2nsv2rK1Kjspi1z GzVtxqXd4KUtIEsSSoGLQ8sW9LCjM7vRW+BHea0JE5hlAf4dejXQ7giV+fdJylPK Q3H9JdUGD8tJVzeXXDgJ8+wWItAdRuQT43Y/v55t6wfMuVwjpISSryHfbfMJ/SfO zfgz4IbHuuLA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=ragREBJBEMxlnzz0T1eitnGFt9b3zovUPd/B2F46z5E=; b=PwylYKWM MykymmaHUMtHScr4qBCVDHtyY5aXBrfQUoMjdZOEzpSZtgcYukyZCI+wT5RF0W66 uQ8rBrO38OYytavE2efNVeaDT7QiT95Iv/bFN0QM1sxqeP4+cKIErb6/TibD2Cvm 7AsoNN9Nuvl+eKiZFU39056a5vpQCugZkPAbsNMo2E6pZki9UQTf+JY9Lt4kWh1j OjtodefiTuR4sq/JvKN3zpesmBuKNTHHxCV4025wgO6fZe5wkdgrpQweTjbALcl5 ACNGIOfZBt/2IR+HyJI6NpoJrE+5gSHdxuaHtAF3Kk+FubL/27p+ZJzFDrW7IJEs F3Nr13hv9+m5jw== X-ME-Sender: X-Sasl-enc: GU0GwqjuTm471mDBfpNoIBkOo2UR7KQl2rmnX4adxoSG 1494858377 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id ABF7C249CC; Mon, 15 May 2017 10:26:17 -0400 (EDT) From: Thomas Monjalon To: "Richardson, Bruce" , "Yigit, Ferruh" Cc: dev@dpdk.org, Yuanhan Liu , Maxime Coquelin , "Chen, Jing D" , "Zhang, Helin" , "Wu, Jingjing" , "Lu, Wenzhuo" , "Ananyev, Konstantin" Date: Mon, 15 May 2017 16:26:16 +0200 Message-ID: <4150352.hFenEnrka8@xps> In-Reply-To: <59AF69C657FD0841A61C55336867B5B066772FFA@IRSMSX104.ger.corp.intel.com> References: <1857248.OtrprS2xZT@xps> <4a758068-a05e-4b67-0647-f3c57a32f23d@intel.com> <59AF69C657FD0841A61C55336867B5B066772FFA@IRSMSX104.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Mon, 15 May 2017 14:26:19 -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 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)?