| Message ID | 20200311230136.63452-1-thomas@monjalon.net (mailing list archive) |
|---|---|
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2747DA056D; Thu, 12 Mar 2020 00:01:47 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0797D1BF94; Thu, 12 Mar 2020 00:01:47 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id DA567FEB for <dev@dpdk.org>; Thu, 12 Mar 2020 00:01:45 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 3FCD41749; Wed, 11 Mar 2020 19:01:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 11 Mar 2020 19:01:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; s=mesmtp; bh=XHD/LN6IE95LWzSFOUiCimf eP4ISX4J+KIiqnJjPe6o=; b=JT6qRh2TAuJRAjyA94MVtuSt/cRXT0HNReD1q/9 KM2sGwLL4BQb5qgxsRjQIAq4jk3DCYS0SfzITx9E1kgY8JF1OwUn4oKwrsgY7W3r kf6AUD+56+7M1xIm9vcp1pC6YXxxxfCuDvilOIdPi8U+rqZMJEsGzKwmOw8gxsbK 4eEg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :message-id:mime-version:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=XHD/LN6IE95LWzSFO UiCimfeP4ISX4J+KIiqnJjPe6o=; b=FPbTMsdc7MSS6c2oJcCFI6QyB8xTxPfAX 2ye8LSG6ma0MoizXxO24sWt1u5rHn9ZVTwJv+RbcsdxkMHbUvRBhFO7p6otaQiP8 Qs0IqBx1jIjiDaMHZuLGbtHl/YlMzAgTvp2alIerFXSCSJbLQijEVH8jHAdetnf0 nAgdNkKR7PC8AwXb1/NFvSCyBGiHXIpvY4KUFWwJlSyQtwnU1T+ekRZnBnpR5pS3 tsZxFCUwIRdlOgiCayhJlhkxxPNWU+CQYCxnxoWRulKgKaviSTz6BEVBdcEv9MpI Pfw1bpXQ/exY2WPFrjBJqMNFFf4ia4ZP3qzZ8oNemNg5+CNiV6zPw== X-ME-Sender: <xms:1W1pXkDX-DRkZeX3mWR1BYmthQf5p3qxO4pTv_mXTq-XFvQX1cnRLA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddvgedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkofgggfestdekredtre dttdenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhho nhhjrghlohhnrdhnvghtqeenucffohhmrghinhepughpughkrdhorhhgnecukfhppeejje drudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: <xmx:1W1pXsdHR4uJTjQNEgQqEQ7HqHZV_RdmuftzcG0YSY9Sg2Wxc7nHcQ> <xmx:1W1pXkv5t3qUSy61m8H1jKRH5wocdaRGToouqr56Sp2M1xTNpJk3dg> <xmx:1W1pXriRXP63s9Gx2SP7olbnNgW0E9lV6X6kLJjzeD2F7ytVstHBRg> <xmx:121pXoRGXL3HpTiKcpgOKFBtLxWDhLt3wvWcHAnDAMUmzLLZr1XiTQ> Received: from xps.monjalon.net (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 01F7D3280064; Wed, 11 Mar 2020 19:01:39 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: dev@dpdk.org Cc: rahul.lakkireddy@chelsio.com, qi.z.zhang@intel.com, xiao.w.wang@intel.com, xavier.huwei@huawei.com, beilei.xing@intel.com, wenzhuo.lu@intel.com, qiming.yang@intel.com, konstantin.ananyev@intel.com, ferruh.yigit@intel.com, jerinj@marvell.com, rmody@marvell.com, shshaikh@marvell.com, maxime.coquelin@redhat.com, xiaolong.ye@intel.com Date: Thu, 12 Mar 2020 00:01:33 +0100 Message-Id: <20200311230136.63452-1-thomas@monjalon.net> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
| Series | refresh NIC features matrix | |
Message
Thomas Monjalon
March 11, 2020, 11:01 p.m. UTC
This series aims to clean-up the big table of ethdev features: http://doc.dpdk.org/guides/nics/overview.html#id1 We could reorganize the information in this table, maybe split it or add/remove some rows. Before going to such reorganization, we should clean it up. The first patch is fixing the look & size of the table with recent sphinx. 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. Please send patches for Chelsio, Huawei, Intel, Marvell and virtio. Thomas Monjalon (3): doc: fix matrix CSS for recent sphinx doc: remove empty columns from NIC features matrix doc: remove similar columns from NIC features matrix doc/guides/conf.py | 16 +++++++++---- doc/guides/nics/features/bnx2x.ini | 1 + doc/guides/nics/features/bnx2x_vf.ini | 18 --------------- doc/guides/nics/features/bonding.ini | 6 ----- doc/guides/nics/features/kni.ini | 7 ------ doc/guides/nics/features/nfp_vf.ini | 29 ------------------------ doc/guides/nics/features/null.ini | 6 ----- doc/guides/nics/features/ring.ini | 6 ----- doc/guides/nics/features/softnic.ini | 9 -------- doc/guides/nics/features/vdev_netvsc.ini | 12 ---------- 10 files changed, 13 insertions(+), 97 deletions(-) delete mode 100644 doc/guides/nics/features/bnx2x_vf.ini delete mode 100644 doc/guides/nics/features/bonding.ini delete mode 100644 doc/guides/nics/features/kni.ini delete mode 100644 doc/guides/nics/features/nfp_vf.ini delete mode 100644 doc/guides/nics/features/null.ini delete mode 100644 doc/guides/nics/features/ring.ini delete mode 100644 doc/guides/nics/features/softnic.ini delete mode 100644 doc/guides/nics/features/vdev_netvsc.ini
Comments
Ping for review and action on follow-up patches please. I hope we won't have to block patches to get things done. Ferruh, I think we need an action plan. 12/03/2020 00:01, Thomas Monjalon: > This series aims to clean-up the big table of ethdev features: > http://doc.dpdk.org/guides/nics/overview.html#id1 > > We could reorganize the information in this table, > maybe split it or add/remove some rows. > Before going to such reorganization, we should clean it up. > > The first patch is fixing the look & size of the table with recent sphinx. > > 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. > > Please send patches for Chelsio, Huawei, Intel, Marvell and virtio.
Hi Thomas: > -----Original Message----- > From: Thomas Monjalon <thomas@monjalon.net> > Sent: Thursday, March 12, 2020 7:02 AM > To: dev@dpdk.org > Cc: rahul.lakkireddy@chelsio.com; Zhang, Qi Z <qi.z.zhang@intel.com>; Wang, > Xiao W <xiao.w.wang@intel.com>; xavier.huwei@huawei.com; Xing, Beilei > <beilei.xing@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Yang, Qiming > <qiming.yang@intel.com>; Ananyev, Konstantin > <konstantin.ananyev@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; > jerinj@marvell.com; rmody@marvell.com; shshaikh@marvell.com; > maxime.coquelin@redhat.com; Ye, Xiaolong <xiaolong.ye@intel.com> > Subject: [PATCH 0/3] refresh NIC features matrix > > This series aims to clean-up the big table of ethdev features: > http://doc.dpdk.org/guides/nics/overview.html#id1 > > We could reorganize the information in this table, maybe split it or add/remove > some rows. > Before going to such reorganization, we should clean it up. > > The first patch is fixing the look & size of the table with recent sphinx. > > 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. Thanks Qi > > Please send patches for Chelsio, Huawei, Intel, Marvell and virtio. > > > Thomas Monjalon (3): > doc: fix matrix CSS for recent sphinx > doc: remove empty columns from NIC features matrix > doc: remove similar columns from NIC features matrix > > doc/guides/conf.py | 16 +++++++++---- > doc/guides/nics/features/bnx2x.ini | 1 + > doc/guides/nics/features/bnx2x_vf.ini | 18 --------------- > doc/guides/nics/features/bonding.ini | 6 ----- > doc/guides/nics/features/kni.ini | 7 ------ > doc/guides/nics/features/nfp_vf.ini | 29 ------------------------ > doc/guides/nics/features/null.ini | 6 ----- > doc/guides/nics/features/ring.ini | 6 ----- > doc/guides/nics/features/softnic.ini | 9 -------- > doc/guides/nics/features/vdev_netvsc.ini | 12 ---------- > 10 files changed, 13 insertions(+), 97 deletions(-) delete mode 100644 > doc/guides/nics/features/bnx2x_vf.ini > delete mode 100644 doc/guides/nics/features/bonding.ini > delete mode 100644 doc/guides/nics/features/kni.ini delete mode 100644 > doc/guides/nics/features/nfp_vf.ini > delete mode 100644 doc/guides/nics/features/null.ini delete mode 100644 > doc/guides/nics/features/ring.ini delete mode 100644 > doc/guides/nics/features/softnic.ini > delete mode 100644 doc/guides/nics/features/vdev_netvsc.ini > > -- > 2.25.1
20/03/2020 06:35, Zhang, Qi Z: > Hi Thomas: > > From: Thomas Monjalon <thomas@monjalon.net> > > > > This series aims to clean-up the big table of ethdev features: > > http://doc.dpdk.org/guides/nics/overview.html#id1 > > > > We could reorganize the information in this table, maybe split it or add/remove > > some rows. > > Before going to such reorganization, we should clean it up. > > > > The first patch is fixing the look & size of the table with recent sphinx. > > > > 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 - you cannot summarize everything in a table - we have two many columns to make it readable I think the right solution is mark features as partially available (P), and give details in the driver guide documentation. Can you please, at least, remove the "vec" columns, as a first step? Thanks
> -----Original Message----- > From: Thomas Monjalon <thomas@monjalon.net> > Sent: Friday, March 20, 2020 6:45 PM > To: Zhang, Qi Z <qi.z.zhang@intel.com> > Cc: dev@dpdk.org; rahul.lakkireddy@chelsio.com; Wang, Xiao W > <xiao.w.wang@intel.com>; xavier.huwei@huawei.com; Xing, Beilei > <beilei.xing@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Yang, Qiming > <qiming.yang@intel.com>; Ananyev, Konstantin > <konstantin.ananyev@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; > jerinj@marvell.com; rmody@marvell.com; shshaikh@marvell.com; > maxime.coquelin@redhat.com; Ye, Xiaolong <xiaolong.ye@intel.com> > Subject: Re: [PATCH 0/3] refresh NIC features matrix > > 20/03/2020 06:35, Zhang, Qi Z: > > Hi Thomas: > > > > From: Thomas Monjalon <thomas@monjalon.net> > > > > > > This series aims to clean-up the big table of ethdev features: > > > http://doc.dpdk.org/guides/nics/overview.html#id1 > > > > > > We could reorganize the information in this table, maybe split it or > > > add/remove some rows. > > > Before going to such reorganization, we should clean it up. > > > > > > The first patch is fixing the look & size of the table with recent sphinx. > > > > > > 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. > - 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, 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. > > Can you please, at least, remove the "vec" columns, as a first step? Sure, as I said, I agree to remove "vec". Thanks Qi > Thanks >
On 3/20/20 2:15 PM, Zhang, Qi Z wrote: > > >> -----Original Message----- >> From: Thomas Monjalon <thomas@monjalon.net> >> Sent: Friday, March 20, 2020 6:45 PM >> To: Zhang, Qi Z <qi.z.zhang@intel.com> >> Cc: dev@dpdk.org; rahul.lakkireddy@chelsio.com; Wang, Xiao W >> <xiao.w.wang@intel.com>; xavier.huwei@huawei.com; Xing, Beilei >> <beilei.xing@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Yang, Qiming >> <qiming.yang@intel.com>; Ananyev, Konstantin >> <konstantin.ananyev@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; >> jerinj@marvell.com; rmody@marvell.com; shshaikh@marvell.com; >> maxime.coquelin@redhat.com; Ye, Xiaolong <xiaolong.ye@intel.com> >> Subject: Re: [PATCH 0/3] refresh NIC features matrix >> >> 20/03/2020 06:35, Zhang, Qi Z: >>> Hi Thomas: >>> >>> From: Thomas Monjalon <thomas@monjalon.net> >>>> >>>> This series aims to clean-up the big table of ethdev features: >>>> http://doc.dpdk.org/guides/nics/overview.html#id1 >>>> >>>> We could reorganize the information in this table, maybe split it or >>>> add/remove some rows. >>>> Before going to such reorganization, we should clean it up. >>>> >>>> The first patch is fixing the look & size of the table with recent sphinx. >>>> >>>> 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. >> >> Can you please, at least, remove the "vec" columns, as a first step? > > Sure, as I said, I agree to remove "vec". > > Thanks > Qi > >> Thanks >> >
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 <thomas@monjalon.net> > >> 20/03/2020 06:35, Zhang, Qi Z: > >>> From: Thomas Monjalon <thomas@monjalon.net> > >>>> 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.
12/03/2020 00:01, Thomas Monjalon: > This series aims to clean-up the big table of ethdev features: > http://doc.dpdk.org/guides/nics/overview.html#id1 > > We could reorganize the information in this table, > maybe split it or add/remove some rows. > Before going to such reorganization, we should clean it up. > > The first patch is fixing the look & size of the table with recent sphinx. > > The second and third patches are removing 8 columns which are > clearly unneeded: > - bnx2x_vf > - bonding > - kni > - nfp_vf > - null > - ring > - softnic > - vdev_netvsc > [...] > Thomas Monjalon (3): > doc: fix matrix CSS for recent sphinx > doc: remove empty columns from NIC features matrix > doc: remove similar columns from NIC features matrix Applied
Call for action below (especially for octeontx2 and virtio): 24/03/2020 09:36, Andrew Rybchenko: > On 3/20/20 2:15 PM, Zhang, Qi Z wrote: > > From: Thomas Monjalon <thomas@monjalon.net> > >> 20/03/2020 06:35, Zhang, Qi Z: > >>> From: Thomas Monjalon <thomas@monjalon.net> > >>>> > >>>> This series aims to clean-up the big table of ethdev features: > >>>> http://doc.dpdk.org/guides/nics/overview.html#id1 > >>>> > >>>> We could reorganize the information in this table, maybe split it or > >>>> add/remove some rows. > >>>> Before going to such reorganization, we should clean it up. [...] > >>>> 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). I see that Intel merged "vec" columns for its PMDs. We are still missing octeontx2 and virtio. In order to make sure the message is received, I suggest blocking any patch in these PMDs until features matrix is fixed. > >>>> 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. Ideally we should remove all these columns (VF to be discussed): > >>>> - cxgbevf > >>>> - fm10k_vf > >>>> - hns3_vf > >>>> - i40e_vf > >>>> - igb_vf > >>>> - ixgbe_vf > >>>> - 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. [...] > > >> - 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. Other opinions about removing/merging VF columns?
On Fri, Apr 17, 2020 at 9:32 AM Thomas Monjalon <thomas@monjalon.net> wrote: > Call for action below (especially for octeontx2 and virtio): > > 24/03/2020 09:36, Andrew Rybchenko: > > On 3/20/20 2:15 PM, Zhang, Qi Z wrote: > > > From: Thomas Monjalon <thomas@monjalon.net> > > >> 20/03/2020 06:35, Zhang, Qi Z: > > >>> From: Thomas Monjalon <thomas@monjalon.net> > > >>>> > > >>>> This series aims to clean-up the big table of ethdev features: > > >>>> http://doc.dpdk.org/guides/nics/overview.html#id1 > > >>>> > > >>>> We could reorganize the information in this table, maybe split it or > > >>>> add/remove some rows. > > >>>> Before going to such reorganization, we should clean it up. > [...] > > >>>> 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). > > I see that Intel merged "vec" columns for its PMDs. > We are still missing octeontx2 and virtio. > In order to make sure the message is received, > I suggest blocking any patch in these PMDs until features matrix is fixed. > > > > >>>> 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. > > Ideally we should remove all these columns (VF to be discussed): > > > >>>> - cxgbevf > > >>>> - fm10k_vf > > >>>> - hns3_vf > > >>>> - i40e_vf > > >>>> - igb_vf > > >>>> - ixgbe_vf > > >>>> - 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. > [...] > > > > >> - 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? > +1 > > > > > >> I think the right solution is mark features as partially available > (P), and give > > >> details in the driver guide documentation. > > Other opinions about removing/merging VF columns? > PF and VF devices can have different feature support. It will be good to keep them separate. If it is difficult to tabulate the capabilities for various devices in a single page, then marking it with (P) is fine. The Driver guide should carry the differences between PF and VF capabilities anyway.