From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 6D0351F5 for <dev@dpdk.org>; Fri, 7 Jul 2017 22:37:09 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 11EBE206E9; Fri, 7 Jul 2017 16:37:09 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 07 Jul 2017 16:37:09 -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=SMj87UjIhaPPQ/f iE2kOD3FT6mgXAKzgi10pxWufU5k=; b=UXbGP5CVx13HjsfN5ytEwZfwFV05NOM oyigabajSeaq0Bbb/MkA+/iIk82O2wM5nmrUZSIuFZNBp2pRWB2OXb0sX52Pq2U1 hKufMr95Qgw4DJo50NVQT5MuoXMpuhWjjjaZ6a52FSa5YGjcS5VF71ex6zGrcou7 R16HsMVZl7jc= 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=SMj87UjIhaPPQ/fiE2kOD3FT6mgXAKzgi10pxWufU5k=; b=DbG51A08 9x8bDAavrEhWxbEsQLiiVC1bYjmxzaM3E/5+NAgSSqT+4qmXSIlzaD8enpoS1qzc MlKZUBk/8rZ6AKPXZBFhuNqLbcabN5npSxt2y2oaXO+VEFoVhBWz8ZqgJL+1vrfr 1TMKkS2aEX18SQ1MEErFxU5wUGEZ7Gf3yTDkTm+qryGEq9TVYBPgs5aGQEtwFFjF 8SM4JTXPj91gEoWdot5nPPBFteD/WNljbg6T9Qtzzq7eSi4rogn2yAU29BQF23vS o4EnbBrcG3JvYLFB7L3qQebxLLWbEXbBDFKOenNih2N4B5/alvfujlTDP+iMlv0a Y3YgqUgmmqXi3A== X-ME-Sender: <xms:9fBfWVE65miimFFlvNW5vzK3GYcaRxzgffJRMqo7cuAoW8XYy5vAzQ> X-Sasl-enc: RbCJbZmfJKxryedxM2cyqgbkhBs856cJe2aDcumHBoJu 1499459828 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 87CD67E4AA; Fri, 7 Jul 2017 16:37:08 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Wiles, Keith" <keith.wiles@intel.com>, "Yigit, Ferruh" <ferruh.yigit@intel.com> Cc: Andrew Rybchenko <arybchenko@solarflare.com>, "Mcnamara, John" <john.mcnamara@intel.com>, dev@dpdk.org, Olivier Matz <olivier.matz@6wind.com> Date: Fri, 07 Jul 2017 22:37:06 +0200 Message-ID: <7382864.ESfvCiQYHC@xps> In-Reply-To: <16A01B5A-84DC-436F-B544-F6258BA739E5@intel.com> References: <20170622190233.67933-1-ferruh.yigit@intel.com> <d33692ba-c96e-c8bf-d6e5-d506c684686a@intel.com> <16A01B5A-84DC-436F-B544-F6258BA739E5@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3] doc: document NIC features X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 07 Jul 2017 20:37:09 -0000 07/07/2017 16:20, Wiles, Keith: > > > On Jul 7, 2017, at 9:13 AM, Ferruh Yigit <ferruh.yigit@intel.com> 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.