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 <tho...@monjalon.net> > >> 20/03/2020 06:35, Zhang, Qi Z: > >>> From: Thomas Monjalon <tho...@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?
