From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id C32EFA034F;
	Sun,  5 Dec 2021 19:00:39 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 581FD4013F;
	Sun,  5 Dec 2021 19:00:39 +0100 (CET)
Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com
 [209.85.216.48]) by mails.dpdk.org (Postfix) with ESMTP id D6A7840040
 for <dev@dpdk.org>; Sun,  5 Dec 2021 19:00:37 +0100 (CET)
Received: by mail-pj1-f48.google.com with SMTP id
 np6-20020a17090b4c4600b001a90b011e06so6510610pjb.5
 for <dev@dpdk.org>; Sun, 05 Dec 2021 10:00:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20210112.gappssmtp.com; s=20210112;
 h=date:from:to:cc:subject:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=X58dlAczY9Hg2K9+4d1pD54XqkcNUmKDniKXIDJaoNA=;
 b=Ldqy/ir7A2OgDe6yll9P2nZSNUTd625l5twEJ1qGfz4/4TPJFWmXhzhIH14s/wHFdu
 L7l+Z1akZypW+8yeJg9I+ZsPThtFA1XjXUpBGcc7KEh8KScPD2YMcebUOJ0ZWY+LPLC3
 qdKC0dGfQ1ghulmYCmfZtbmuqfcUN9dfD91gaTItXZsNdX8Xw9TbQsY4JD2AxBWANx7H
 6sT83j1OqRYvYIb3S3thzhUMb2KOpS0huWDu6JhuGWiOAtsw8r7PdXbBBZWkvPfKpd8q
 LeKH6SpadwISOXEV0GF07u8ikXolbvnGgzI9pPkuFE515YyjSFG5QJKlp3uRlaP/zYyK
 6Mhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=X58dlAczY9Hg2K9+4d1pD54XqkcNUmKDniKXIDJaoNA=;
 b=Aq+e8rTPx3QvAHQHMvDZbDV8s4M8zh6GPuohR2grrxObKCURKM5w16T+t/vsD50xpv
 8sqZ/UCz3fmWc/jao5uTYglv6A7Pxwj0UEYhTGOxIkFQZajJw4mOPlOgloPAIXMb2Nn/
 4PGZh4dPNZmbcJXSK74x0xsQzYkwUfiG0eSdgKK9+Qz2uYwj8ncBFkZcmFj9a03FhEh5
 xol5NQhNXrtCQa2jrNo9GNjBJvHF1ldi3s0gWiMUSxyECS+8cu7r7P1d84ZoS0PmpDeE
 S8I8Z8TRgpCRRyXEsO10oFV16OgYSUycCcmSfAxid88G+d40y1z5Az39atNA35xWv0Fz
 tekg==
X-Gm-Message-State: AOAM531ZvJzUZMHR1g0yZmJ4OLeUxybc92b/dC5egkHFtNZYkgJE5UZm
 jAZfTuQwU62vozxrcE6v9kEwZA==
X-Google-Smtp-Source: ABdhPJykSST3P9bRcAxDfPOiil82jkqdF0K7gp9DJRes9TD1iVn738FtgSB/m7eCe5XsqsBO5ra1yQ==
X-Received: by 2002:a17:90b:1b52:: with SMTP id
 nv18mr31574325pjb.43.1638727236642; 
 Sun, 05 Dec 2021 10:00:36 -0800 (PST)
Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123])
 by smtp.gmail.com with ESMTPSA id 130sm9482589pfu.13.2021.12.05.10.00.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 05 Dec 2021 10:00:36 -0800 (PST)
Date: Sun, 5 Dec 2021 10:00:31 -0800
From: Stephen Hemminger <stephen@networkplumber.org>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: Jerin Jacob <jerinj@marvell.com>, dpdk-dev <dev@dpdk.org>, Ray Kinsella
 <mdr@ashroe.eu>, Thomas Monjalon <thomas@monjalon.net>, Ferruh Yigit
 <ferruh.yigit@intel.com>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
 Ajit Khaparde <ajit.khaparde@broadcom.com>, Andrew Boyer
 <aboyer@pensando.io>, Beilei Xing <beilei.xing@intel.com>, "Richardson,
 Bruce" <bruce.richardson@intel.com>, Chas Williams <chas3@att.com>, "Xia,
 Chenbo" <chenbo.xia@intel.com>, Ciara Loftus <ciara.loftus@intel.com>,
 Devendra Singh Rawat <dsinghrawat@marvell.com>, Ed Czeck
 <ed.czeck@atomicrules.com>, Evgeny Schemeilin <evgenys@amazon.com>, Gaetan
 Rivet <grive@u256.net>, Gagandeep Singh <g.singh@nxp.com>, Guoyang Zhou
 <zhouguoyang@huawei.com>, Haiyue Wang <haiyue.wang@intel.com>, Harman Kalra
 <hkalra@marvell.com>, heinrich.kuhn@corigine.com, Hemant Agrawal
 <hemant.agrawal@nxp.com>, Hyong Youb Kim <hyonkim@cisco.com>, Igor Chauskin
 <igorch@amazon.com>, Igor Russkikh <irusskikh@marvell.com>, Jakub Grajciar
 <jgrajcia@cisco.com>, Jasvinder Singh <jasvinder.singh@intel.com>, Jian
 Wang <jianwang@trustnetic.com>, Jiawen Wu <jiawenwu@trustnetic.com>,
 Jingjing Wu <jingjing.wu@intel.com>, John Daley <johndale@cisco.com>, John
 Miller <john.miller@atomicrules.com>, "John W. Linville"
 <linville@tuxdriver.com>, "Wiles, Keith" <keith.wiles@intel.com>, Kiran
 Kumar K <kirankumark@marvell.com>, Lijun Ou <oulijun@huawei.com>, Liron
 Himi <lironh@marvell.com>, Long Li <longli@microsoft.com>, Marcin Wojtas
 <mw@semihalf.com>, Martin Spinler <spinler@cesnet.cz>, Matan Azrad
 <matan@nvidia.com>, Matt Peters <matt.peters@windriver.com>, Maxime
 Coquelin <maxime.coquelin@redhat.com>, Michal Krawczyk <mk@semihalf.com>,
 "Min Hu (Connor" <humin29@huawei.com>, Pradeep Kumar Nalla
 <pnalla@marvell.com>, Nithin Dabilpuram <ndabilpuram@marvell.com>, Qiming
 Yang <qiming.yang@intel.com>, Qi Zhang <qi.z.zhang@intel.com>, Radha Mohan
 Chintakuntla <radhac@marvell.com>, Rahul Lakkireddy
 <rahul.lakkireddy@chelsio.com>, Rasesh Mody <rmody@marvell.com>, Rosen Xu
 <rosen.xu@intel.com>, Sachin Saxena <sachin.saxena@oss.nxp.com>, Satha
 Koteswara Rao Kottidi <skoteshwar@marvell.com>, Shahed Shaikh
 <shshaikh@marvell.com>, Shai Brandes <shaibran@amazon.com>, Shepard Siegel
 <shepard.siegel@atomicrules.com>, Somalapuram Amaranath <asomalap@amd.com>,
 Somnath Kotur <somnath.kotur@broadcom.com>, Stephen Hemminger
 <sthemmin@microsoft.com>, Steven Webster <steven.webster@windriver.com>,
 Sunil Kumar Kori <skori@marvell.com>, Tetsuya Mukawa <mtetsuyah@gmail.com>,
 Veerasenareddy Burru <vburru@marvell.com>, Viacheslav Ovsiienko
 <viacheslavo@nvidia.com>, Xiao Wang <xiao.w.wang@intel.com>, Xiaoyun Wang
 <cloud.wangxiaoyun@huawei.com>, Yisen Zhuang <yisen.zhuang@huawei.com>,
 Yong Wang <yongwang@vmware.com>, Ziyang Xuan <xuanziyang2@huawei.com>
Subject: Re: [dpdk-dev] [PATCH] ethdev: support queue-based priority flow
 control
Message-ID: <20211205100031.7be8e7b0@hermes.local>
In-Reply-To: <CALBAE1NYzb0AHCN0krd0RmkNAaU2xFUF2mS=byHvKbJRd6HK4Q@mail.gmail.com>
References: <20211204172458.1904300-1-jerinj@marvell.com>
 <20211204093835.4ef4219c@hermes.local>
 <CALBAE1NYzb0AHCN0krd0RmkNAaU2xFUF2mS=byHvKbJRd6HK4Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
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

On Sun, 5 Dec 2021 12:33:57 +0530
Jerin Jacob <jerinjacobk@gmail.com> wrote:

> On Sat, Dec 4, 2021 at 11:08 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > On Sat, 4 Dec 2021 22:54:58 +0530
> > <jerinj@marvell.com> wrote:
> >  
> > > +     /**
> > > +      * Maximum supported traffic class as per PFC (802.1Qbb) specification.
> > > +      *
> > > +      * Based on device support and use-case need, there are two different
> > > +      * ways to enable PFC. The first case is the port level PFC
> > > +      * configuration, in this case, rte_eth_dev_priority_flow_ctrl_set()
> > > +      * API shall be used to configure the PFC, and PFC frames will be
> > > +      * generated using based on VLAN TC value.
> > > +      * The second case is the queue level PFC configuration, in this case,
> > > +      * Any packet field content can be used to steer the packet to the
> > > +      * specific queue using rte_flow or RSS and then use
> > > +      * rte_eth_dev_priority_flow_ctrl_queue_set() to set the TC mapping
> > > +      * on each queue. Based on congestion selected on the specific queue,
> > > +      * configured TC shall be used to generate PFC frames.
> > > +      *
> > > +      * When set to non zero value, application must use queue level
> > > +      * PFC configuration via rte_eth_dev_priority_flow_ctrl_queue_set() API
> > > +      * instead of port level PFC configuration via
> > > +      * rte_eth_dev_priority_flow_ctrl_set() API to realize
> > > +      * PFC configuration.
> > > +      */
> > > +     uint8_t pfc_queue_tc_max;
> > > +     uint8_t reserved_8s[7];
> > > +     uint64_t reserved_64s[1]; /**< Reserved for future fields */
> > >       void *reserved_ptrs[2];   /**< Reserved for future fields */  
> >
> > Not sure you can claim ABI compatibility because the previous versions of DPDK
> > did not enforce that reserved fields must be zero.  The Linux kernel
> > learned this when adding flags for new system calls; reserved fields only
> > work if you enforce that application must set them to zero.  
> 
> In this case it rte_eth_dev_info is an out parameter and implementation of
> rte_eth_dev_info_get() already memseting to 0.
> Do you still see any other ABI issue?
> 
> See rte_eth_dev_info_get()
>         /*
>          * Init dev_info before port_id check since caller does not have
>          * return status and does not know if get is successful or not.
>          */
>         memset(dev_info, 0, sizeof(struct rte_eth_dev_info));

The concern was from the misreading comment.  It talks about what application should do.
Could you reword the comment so that it describes what pfc_queue_tc_max is here
and move the flow control set part of the comment to where the API for that is.