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 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 ; Fri, 17 Apr 2020 20:21:48 +0200 (CEST) Received: by mail-oi1-f195.google.com with SMTP id r25so2886227oij.4 for ; 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 Date: Fri, 17 Apr 2020 11:21:31 -0700 Message-ID: To: Thomas Monjalon Cc: dpdk-dev , "jerinj@marvell.com" , "maxime.coquelin@redhat.com" , "Ye, Xiaolong" , Nithin Dabilpuram , Kiran Kumar K , Zhihong Wang , "Zhang, Qi Z" , "rahul.lakkireddy@chelsio.com" , "Wang, Xiao W" , "xavier.huwei@huawei.com" , "Xing, Beilei" , "Lu, Wenzhuo" , "Yang, Qiming" , "Ananyev, Konstantin" , "Yigit, Ferruh" , "rmody@marvell.com" , "shshaikh@marvell.com" , Andrew Rybchenko 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Apr 17, 2020 at 9:32 AM Thomas Monjalon 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 > > >> 20/03/2020 06:35, Zhang, Qi Z: > > >>> From: 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. > [...] > > >>>> 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.