From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Keith" Subject: Re: [PATCH v3] doc: document NIC features Date: Fri, 7 Jul 2017 14:20:33 +0000 Message-ID: <16A01B5A-84DC-436F-B544-F6258BA739E5@intel.com> References: <20170622190233.67933-1-ferruh.yigit@intel.com> <8948822.3HyaHf9bfD@xps> <1f389cf5-ed5d-0768-ab91-76f458a0c219@intel.com> <1676793.i6e7ich7X3@xps> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Thomas Monjalon , Andrew Rybchenko , "Mcnamara, John" , "dev@dpdk.org" , Olivier Matz To: "Yigit, Ferruh" Return-path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 78F6C235 for ; Fri, 7 Jul 2017 16:20:36 +0200 (CEST) In-Reply-To: Content-Language: en-US Content-ID: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > On Jul 7, 2017, at 9:13 AM, Ferruh Yigit wrote: >=20 > 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=20 >>>>>> usual). Ideally >>>>>> we need common way to highlight it. May be it is OK that control pat= h=20 >>>>>> features are duplicated >>>>>> in this case, but ideally it should be expressed somehow. >>>>>=20 >>>>> I agree different datapath implementations can be documented better, = I >>>>> just don't know how to do ... >>>>>=20 >>>>> For some drivers there are multiple vector implementations and the >>>>> feature set for them is not clear. And as you said control features a= re >>>>> duplicated in the table. >>>>>=20 >>>>> Perhaps control and datapath features can be separated. >>>>>=20 >>>>> 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 i= f >>>>> both scalar and vector has support for it. But this is not solving >>>>> multiple vector implementation problem. >>>>=20 >>>> 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 shoul= d >>>> be marked as partially supported... and the developers must implement = it. >>>=20 >>> But for example for i40e, there are altivec, neon and sse vector >>> implementations, how should we document this? >>=20 >> 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. >=20 > 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 id= entify these NICs plus show the features. Having multiple lines in a table is not difficult and helps identify exactl= y what is supported on all platforms. Regards, Keith