From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id A185C16E for ; Mon, 15 May 2017 15:15:23 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2017 06:15:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,345,1491289200"; d="scan'208";a="1169369425" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.42]) by fmsmga002.fm.intel.com with SMTP; 15 May 2017 06:15:18 -0700 Received: by (sSMTP sendmail emulation); Mon, 15 May 2017 14:15:18 +0100 Date: Mon, 15 May 2017 14:15:17 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: ferruh.yigit@intel.com, dev@dpdk.org, Yuanhan Liu , Maxime Coquelin , Jing Chen , Helin Zhang , Jingjing Wu , Wenzhuo Lu , Konstantin Ananyev Message-ID: <20170515131517.GA68644@bricha3-MOBL3.ger.corp.intel.com> References: <1857248.OtrprS2xZT@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1857248.OtrprS2xZT@xps> 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: Mon, 15 May 2017 13:15:24 -0000 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. /Bruce