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 AF327A04C5; Fri, 4 Sep 2020 17:30:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DEB551C0CD; Fri, 4 Sep 2020 17:30:49 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id DF6D81C0B4 for ; Fri, 4 Sep 2020 17:30:47 +0200 (CEST) IronPort-SDR: JJqg4ly/7+ccoXYDSxsHp/7iQ2Wadq9wc5/w4GE1KD1pgSIXdVaZk4JLmtRRVnBbROxXPggqlZ KCxzWjPwPVFQ== X-IronPort-AV: E=McAfee;i="6000,8403,9734"; a="137281435" X-IronPort-AV: E=Sophos;i="5.76,389,1592895600"; d="scan'208";a="137281435" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Sep 2020 08:30:46 -0700 IronPort-SDR: l8p7F3rRKuNL4FQlLnUgg/FPkdgFPmEKov0aDQF4R7IhCMIWVGgw5H1ANwJ+wBWsoOgEcPBdJ5 Z6vN6F7F0ZBg== X-IronPort-AV: E=Sophos;i="5.76,389,1592895600"; d="scan'208";a="302666654" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.4.76]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 04 Sep 2020 08:30:44 -0700 Date: Fri, 4 Sep 2020 16:30:40 +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: <20200904153040.GD305@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. Allow me to explain a bit further. For example, we add a new field to the end of the configuration struct or the info struct, which changes the size of the structure. We use function versioning to allow old and new ethdev config APIs. The new API function just works passing the structure through to the driver API. However, the old API implementation has a problem, because it has just been passed a structure that is too small for use by the driver functions, so it can't just pass it along. Therefore, the code has two choices (that I am aware of): 1. allocate a new structure of the correct size, and call the driver API with that. Once it returns, copy the fields over to the old structure to return to the user. 2. create a new function pointer in the ops array for legacy compatibility and have each driver implement a function to work with the old structure. The alternative scheme is just to pass around the structure size. The configure ethdev API takes the pointer and size, and does not need changing if it does not use any new fields, just passes them through to the driver configure API. Similarly there, any drivers that don't access the new fields don't need changing, while those that do access them just need to check the struct size before doing so to see what version of the structure has been received. > > And I think this kind of runtime checks should be discussed for all or none > APIs, instead of having them only for some APIs. Yes, I agree with that. Incidentally, this same idea was covered in the context of system calls at the linux plumbers conf: https://linuxplumbersconf.org/event/7/contributions/657/attachments/639/1159/extensible_syscalls.pdf Regards, /Bruce