From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v3] doc: document NIC features Date: Fri, 07 Jul 2017 22:37:06 +0200 Message-ID: <7382864.ESfvCiQYHC@xps> References: <20170622190233.67933-1-ferruh.yigit@intel.com> <16A01B5A-84DC-436F-B544-F6258BA739E5@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Andrew Rybchenko , "Mcnamara, John" , dev@dpdk.org, Olivier Matz To: "Wiles, Keith" , "Yigit, Ferruh" Return-path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 6D0351F5 for ; Fri, 7 Jul 2017 22:37:09 +0200 (CEST) In-Reply-To: <16A01B5A-84DC-436F-B544-F6258BA739E5@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 07/07/2017 16:20, Wiles, Keith: > > > On Jul 7, 2017, at 9:13 AM, Ferruh Yigit wrote: > > > > On 7/7/2017 3:02 PM, Thomas Monjalon wrote: > >> 07/07/2017 15:57, Ferruh Yigit: > >>> On 7/7/2017 2:53 PM, Thomas Monjalon wrote: > >>>> 07/07/2017 15:37, Ferruh Yigit: > >>>>> On 7/7/2017 11:55 AM, Andrew Rybchenko wrote: > >>>>>> Also some PMDs have few implementations of the datapath (like vector and > >>>>>> usual). Ideally > >>>>>> we need common way to highlight it. May be it is OK that control path > >>>>>> features are duplicated > >>>>>> in this case, but ideally it should be expressed somehow. > >>>>> > >>>>> I agree different datapath implementations can be documented better, I > >>>>> just don't know how to do ... > >>>>> > >>>>> For some drivers there are multiple vector implementations and the > >>>>> feature set for them is not clear. And as you said control features are > >>>>> duplicated in the table. > >>>>> > >>>>> Perhaps control and datapath features can be separated. > >>>>> > >>>>> Or as Thomas suggested sometime ago, vector and scalar version can be > >>>>> merged into one in the table and feature can be marked as supported if > >>>>> both scalar and vector has support for it. But this is not solving > >>>>> multiple vector implementation problem. > >>>> > >>>> Yes it is the way to go. > >>>> The features should not be different from a datapath implementation to > >>>> another one. So they must be merged in only one column. > >>>> If a feature is not supported in every datapaths of a driver, it should > >>>> be marked as partially supported... and the developers must implement it. > >>> > >>> But for example for i40e, there are altivec, neon and sse vector > >>> implementations, how should we document this? > >> > >> They are all only one i40 driver. It should offer the same features > >> regardless of the platform it runs on. > >> So it should be only one column in the table. > > > > If one platform does not implements a feature, it will cause feature > > will be documented as partial independent from other platform's status, > > this is unfair for the ones implemented it. > > +1 > > If a single PMD supports different platforms, then we need to be able to identify these NICs plus show the features. > Having multiple lines in a table is not difficult and helps identify exactly what is supported on all platforms. No, you miss the point. I don't care about the table, it is just a tool to target uniform implementation. DPDK must be multi-platform. It means an application relying on a feature must work when changing the CPU. If a PMD maintainer wants its features advertised as fully supported, he must reject partial datapath implementation. It is fair because it is the maintainer's choice.