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 801FEA04C5; Fri, 4 Sep 2020 17:14:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9073C1C0C6; Fri, 4 Sep 2020 17:14:12 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 8C1461C0C2 for ; Fri, 4 Sep 2020 17:14:10 +0200 (CEST) IronPort-SDR: S7XFyJgoaFKxxpchmrw+NlMBjjAz+2ddE8lWDHunI4pqefiqJtNZOFToqRkkqiRoPqd75LK7CH BbFAS3azX2kA== X-IronPort-AV: E=McAfee;i="6000,8403,9734"; a="158733930" X-IronPort-AV: E=Sophos;i="5.76,389,1592895600"; d="scan'208";a="158733930" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Sep 2020 08:14:09 -0700 IronPort-SDR: NVeKEdvJlmGb9U+tisZA31RhOSoNUj7l5UZ7dC/EXTsFHQcPaZM5aNnxDt9117imFGxjiiDFPA ioyPZOuHsG1Q== X-IronPort-AV: E=Sophos;i="5.76,389,1592895600"; d="scan'208";a="503539662" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.4.76]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 04 Sep 2020 08:14:07 -0700 Date: Fri, 4 Sep 2020 16:14:04 +0100 From: Bruce Richardson To: Ferruh Yigit Cc: Chengchang Tang , dev@dpdk.org, linuxarm@huawei.com, thomas@monjalon.net, arybchenko@solarflare.com, wenzhuo.lu@intel.com, maryam.tahhan@intel.com Message-ID: <20200904151404.GC305@bricha3-MOBL.ger.corp.intel.com> References: <1592483709-7076-1-git-send-email-tangchengchang@huawei.com> <1598685199-1630-1-git-send-email-tangchengchang@huawei.com> <1598685199-1630-2-git-send-email-tangchengchang@huawei.com> <20200903153526.GB1621@bricha3-MOBL.ger.corp.intel.com> <161ed434-fe6b-c471-c505-cfb2c9739f00@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <161ed434-fe6b-c471-c505-cfb2c9739f00@intel.com> Subject: Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add a field for rxq info structure 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, Sep 04, 2020 at 03:25:26PM +0100, Ferruh Yigit wrote: > On 9/3/2020 4:35 PM, Bruce Richardson wrote: > > On Sat, Aug 29, 2020 at 03:13:16PM +0800, Chengchang Tang wrote: > >> Add a field named rx_buf_size in rte_eth_rxq_info to indicate the buffer > >> size used in receiving packets for HW. > >> > >> In this way, upper-layer users can get this information by calling > >> rte_eth_rx_queue_info_get. > >> > >> Signed-off-by: Chengchang Tang > >> Reviewed-by: Wei Hu (Xavier) > >> Acked-by: Andrew Rybchenko > >> --- > >> lib/librte_ethdev/rte_ethdev.h | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h > >> index 70295d7..9fed5cb 100644 > >> --- a/lib/librte_ethdev/rte_ethdev.h > >> +++ b/lib/librte_ethdev/rte_ethdev.h > >> @@ -1420,6 +1420,8 @@ struct rte_eth_rxq_info { > >> struct rte_eth_rxconf conf; /**< queue config parameters. */ > >> uint8_t scattered_rx; /**< scattered packets RX supported. */ > >> uint16_t nb_desc; /**< configured number of RXDs. */ > >> + /**< buffer size used for hardware when receive packets. */ > >> + uint16_t rx_buf_size; > >> } __rte_cache_min_aligned; > >> > > Since this is breaking the ABI, this looks like the perfect opportunity to > > add in a qinfo_size parameter to rte_eth_rx_queue_info_get() call which > > allows ABI sanity-checking. Also, if passed through to the individual > > drivers, allows them to make ABI determinations since driver functions > > cannot be versioned, i.e. the driver info function cannot know whether it > > has been called by queue_info_v21 or queue_info_v22. > > > > Current approach we have is to detect the ABI breakage before release and either > block it or use ABI versioning. > What you suggest to add runtime checks assumes application can call old and new > APIs, which is not our case and not sure what this runtime check adds. > > The option to use runtime check between library and driver can be needed if > library and driver from different DPDK versions can be used together, I think > enabling this can bring more complexity and better to use all components of a > DPDK release together. > > And I think this kind of runtime checks should be discussed for all or none > APIs, instead of having them only for some APIs. No the main concern here is to avoid the kind of ABI issues that hit the crypto tree in a recent release. Passing the length of the array around would actually make the regular versioning simpler (as I think we wouldn't need to use the fancy linker versioning), but the main benefit is if that info can be passed through to the driver layer, since driver functions called via ethdev cannot be versioned. /Bruce