From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id ADC75A0588; Thu, 16 Apr 2020 22:13:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1D5DA1DE26; Thu, 16 Apr 2020 22:13:24 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id 09E7E1DE13 for ; Thu, 16 Apr 2020 22:13:22 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 27F615803B7; Thu, 16 Apr 2020 16:13:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 16 Apr 2020 16:13:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=mpH0CD/pHJIcFUpSevZG0mghKez07zQEvv9m6mjQ+uw=; b=OLIOV0iJrCcw 4+chimSEP63FQH+8FL6no75yYAumCBQ76GIgvBIljFB3WxqlUx5x9Vig92H/EhyR NY+KVwbzOmUXfiYfxjhhR13WKJSdydO0b2nIfrGcf3ofB/0HoFVuNrEsC1/EGnNE 6UsunZzDQBYf7t1JfqBS8tkm37d61Ds= 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=mpH0CD/pHJIcFUpSevZG0mghKez07zQEvv9m6mjQ+ uw=; b=4ehIQ6/4SmpG2B/YlLs/i9Yjng/OkLpXu4hrSUFIrsQw+S2CaaiMKwlti YcH65nKd/4mDA5stS/yJgf4FZuc75RWUoOe50ICrPIDHPh1kjYHAogLs+XZmVBcN r5QBal8THIqMiG/o856kjgJjCamRA/LAFH+uqvFHW8nH0yaHDuIXhExWhHIrhBZ3 q9TyC4OMhpq7ovLjcqwc/wlWNYSUmqRCxUU1aWoxZgFagWYL4EjHGtHgChTUr1wh FkCP3IH3PEsLTzgN2KdfUXaf5VgEprGR5uYPqOejaiMqUZ2rrZNk5mxiGu99BPU3 O203XWMMXnDOoNgoBZT7B7+xwt8Pg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeehgddugeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id E159C3060060; Thu, 16 Apr 2020 16:13:18 -0400 (EDT) From: Thomas Monjalon To: dev@dpdk.org Cc: "Zhang, Qi Z" , "rahul.lakkireddy@chelsio.com" , "Wang, Xiao W" , "xavier.huwei@huawei.com" , "Xing, Beilei" , "Lu, Wenzhuo" , "Yang, Qiming" , "Ananyev, Konstantin" , "Yigit, Ferruh" , "jerinj@marvell.com" , "rmody@marvell.com" , "shshaikh@marvell.com" , "maxime.coquelin@redhat.com" , "Ye, Xiaolong" , Andrew Rybchenko , galco@mellanox.com, david.marchand@redhat.com Date: Thu, 16 Apr 2020 22:13:17 +0200 Message-ID: <6114480.a9HWlOh95j@thomas> In-Reply-To: <26aaaba9-ac76-c917-a00e-145e3e2d0432@solarflare.com> References: <20200311230136.63452-1-thomas@monjalon.net> <039ED4275CED7440929022BC67E70611547E55AD@SHSMSX103.ccr.corp.intel.com> <26aaaba9-ac76-c917-a00e-145e3e2d0432@solarflare.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 0/3] refresh NIC features matrix 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Any more opinion about removing VF columns from the NIC matrix? 24/03/2020 09:36, Andrew Rybchenko: > On 3/20/20 2:15 PM, Zhang, Qi Z wrote: > > From: Thomas Monjalon > >> 20/03/2020 06:35, Zhang, Qi Z: > >>> From: Thomas Monjalon > >>>> The second and third patches are removing 8 columns which are > >>>> clearly > >>>> unneeded: > >>>> - bnx2x_vf > >>>> - bonding > >>>> - kni > >>>> - nfp_vf > >>>> - null > >>>> - ring > >>>> - softnic > >>>> - vdev_netvsc > >>>> > >>>> More columns can be removed by merging PF/VF and vector datapaths. > >>>> If a feature cannot be supported in all cases, it should be marked > >>>> as partially supported (P). > >>>> If a feature is PF-specific (like flow control), that's OK to mark > >>>> it fully supported because it's obviously impossible for VF. > >>>> There are also some features which were probably marked in some > >>>> columns and missed in its VF or vector counterpart. > >>>> Please work to merge and drop these 16 columns: > >>>> - cxgbevf > >>>> - fm10k_vf > >>>> - hns3_vf > >>>> - i40e_vec > >>>> - i40e_vf > >>>> - i40e_vf_vec > >>>> - iavf_vec > >>>> - ice_vec > >>>> - igb_vf > >>>> - ixgbe_vec > >>>> - ixgbe_vf > >>>> - ixgbe_vf_vec > >>>> - octeontx2_vec > >>>> - octeontx2_vf > >>>> - qede_vf > >>>> - virtio_vec > >>>> > >>>> The total gain is to reduce the table size from 71 to 47 columns. > >>> > >>> I agree to remove all the column with "vec", since vector PMD can be > >> regarded as a feature of the a PMD. > >>> But I'm not sure if it is a good idea to merge VF and PF into one column. > >>> From my view, for intel device, VF driver and PF driver just share the code, > >> but they actually are running at two different context. > >>> And likely they will support different feature, merge into one column may > >> confuse our customer if they want to understand what exactly the PMD > >> support. > >> > >> I understand you have 2 different datapaths. > >> My arguments are: > >> - it is the same NIC > > > > Yes, but one device can be polymorphic, ideally i40e and i40evf could be in two different folder, and the common part can be a library in driver/common/i40e. > > For me, it does not sound like a good idea. Too many folders on > the first level does not look nice. Should we go Linux way and > group by vendor? Too early? However, it is not directly > related to the topic. > > >> - you cannot summarize everything in a table > >> - we have two many columns to make it readable > > > > I don't think columns number is critical, typically user just need to focus on the first column and the specific driver's column, > > Too many columns still makes it harder to read/analyze. I think > the main goal of the table is too help making NIC choice to > be installed in a server and you can't make a choice between > PF and VF. Difference between PF and VF capabilities is > a separate story and out-of-scope of the table. > We have a new driver(s) in each DPDK release and table is > already big and will grow more and more. > > > I guess it may not a big challenge to enable some filter by front end web technique? > > > >> I think the right solution is mark features as partially available (P), and give > >> details in the driver guide documentation.