From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 6A6ECA0597;
	Fri, 17 Apr 2020 20:21:50 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id B86A51E49D;
	Fri, 17 Apr 2020 20:21:49 +0200 (CEST)
Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com
 [209.85.167.195]) by dpdk.org (Postfix) with ESMTP id BA0851D59C
 for <dev@dpdk.org>; Fri, 17 Apr 2020 20:21:48 +0200 (CEST)
Received: by mail-oi1-f195.google.com with SMTP id r25so2886227oij.4
 for <dev@dpdk.org>; Fri, 17 Apr 2020 11:21:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Q9ZvXORxr6BelkbTS33+cnHHAktBg1ncENiWihFS3FA=;
 b=MlssFACfVYd/viyx0aQ0lI+OIKs5AuBaSthRQRMwrU4PeHP4Knsjqt790RArvsC+YQ
 5teDmhKYXFz097y+XC9Mu3DAyz/b4547C9Pj31AO9v1c4FK4mcpfAOJ71RqHYsgwoTbW
 js/3HUtOHcqfUqGu1d1f3apBd+6OLGaEVoCgw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=Q9ZvXORxr6BelkbTS33+cnHHAktBg1ncENiWihFS3FA=;
 b=i8pbCU3/OKyX8Ltlt07p5Sc8eNtWAGRt4jSNFrU2QlIdd/Z0iOqV9eJBW1F3gweIhJ
 TY9YN7sFhaZxAciyuNlQY46go83QML2TNYqGuXCkOeOwJDe9L1/GtVs3k0H0r/ierELB
 pT0ZQBUn56ZBEx3OwGavmcGHZ6b2us5WSDSFdZxPdj6jN1AAjooYxU1u2t7IbDyRadoZ
 gDoLms81A0vAssKMoNjNv9JDoI8wM+V5tBPqM+yJCRpHO80dqcEla6TBsdXnMqZu8bPD
 7DBKVP5j4a7Jytw7eJzrpNmoArVwqB/CstSphcxx1kvuiQl1gcXcjmPCexjnQTFJAw99
 YktQ==
X-Gm-Message-State: AGi0Pub/jaJ7clmUDkAgQLshXbnIfiebnPb1uvpQLDagAnjJyKSqVWo7
 HYgIkWnQpnNX5eGqt3MosVnrK5MIUeVSyfvTirkF8g==
X-Google-Smtp-Source: APiQypKgn7a8fxMKKMY3PlA5G8T1GwKmfZv+567rPPiYVeNXo1TIQzd8Sk5yAHNjhFfrLn/uYMDL+AffnCOf8BOrgKk=
X-Received: by 2002:aca:bbc6:: with SMTP id l189mr3181699oif.168.1587147707514; 
 Fri, 17 Apr 2020 11:21:47 -0700 (PDT)
MIME-Version: 1.0
References: <20200311230136.63452-1-thomas@monjalon.net>
 <039ED4275CED7440929022BC67E70611547E55AD@SHSMSX103.ccr.corp.intel.com>
 <26aaaba9-ac76-c917-a00e-145e3e2d0432@solarflare.com>
 <8045952.dE46n4Xy2H@thomas>
In-Reply-To: <8045952.dE46n4Xy2H@thomas>
From: Ajit Khaparde <ajit.khaparde@broadcom.com>
Date: Fri, 17 Apr 2020 11:21:31 -0700
Message-ID: <CACZ4nhtgycgNOK71-sg87N=ODGP-8dPjFdXHc4rjmKoM6_+aQA@mail.gmail.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dpdk-dev <dev@dpdk.org>, "jerinj@marvell.com" <jerinj@marvell.com>, 
 "maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>, "Ye,
 Xiaolong" <xiaolong.ye@intel.com>, 
 Nithin Dabilpuram <ndabilpuram@marvell.com>,
 Kiran Kumar K <kirankumark@marvell.com>, 
 Zhihong Wang <zhihong.wang@intel.com>, "Zhang, Qi Z" <qi.z.zhang@intel.com>, 
 "rahul.lakkireddy@chelsio.com" <rahul.lakkireddy@chelsio.com>, "Wang,
 Xiao W" <xiao.w.wang@intel.com>, 
 "xavier.huwei@huawei.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>, "rmody@marvell.com" <rmody@marvell.com>,
 "shshaikh@marvell.com" <shshaikh@marvell.com>, 
 Andrew Rybchenko <arybchenko@solarflare.com>
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
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 <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>

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.