From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0818AA0524; Fri, 23 Apr 2021 14:35:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E8912410EB; Fri, 23 Apr 2021 14:35:56 +0200 (CEST) Received: from dal2relay132.mxroute.com (dal2relay132.mxroute.com [64.40.26.132]) by mails.dpdk.org (Postfix) with ESMTP id CDAA7410D8 for ; Fri, 23 Apr 2021 14:35:55 +0200 (CEST) Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by dal2relay132.mxroute.com (ZoneMTA) with ESMTPSA id 178febaaf21000881b.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 23 Apr 2021 12:35:50 +0000 X-Zone-Loop: aa8436889dfacc465210805e5e61cf361756c6a8790a X-Originating-IP: [149.28.56.236] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=SaxPP5OrHaamvs69sQ9VEOVLG3UW9dEmzEimbCCIFyM=; b=g8sZpXkUd6ebXrPchx9JKunjzN lNrX9Rjc/LLuTUFehrlRQwIKmOGlD+9W/FgOh99sWQ178nvzoCqG8g234OWEb+bpx81LG4ylVTbi+ FZqeRMEk8Zm72M+6ewZ4W8Cfk1+nVQeVruuHB2jONFbspISnqcHr9+4HXJewzBdo25gGdgQDroeyR k1aXpZdUpaJ2TQkaHbPAUE1CP9TDjshQ3Ik5EGq/PnaQJWjeTg3Eb4uevjnQ8aGt40heN+jDK+8sH vrMgB6fZPaTJ5e4RtRnT8SkJS/zYw4lYh6RkT3fiQF5pxLGF34+Rx7/NzbQzRRTVoUVEPIebjHyDM +JUwjUWQ==; To: =?UTF-8?Q?Ga=c3=abtan_Rivet?= , Thomas Monjalon , "Xueming(Steven) Li" Cc: Gaetan Rivet , dev@dpdk.org, Asaf Penso , David Marchand References: <1608304614-13908-2-git-send-email-xuemingl@nvidia.com> <1618283653-16510-1-git-send-email-xuemingl@nvidia.com> <2917281.N2CalQlgY7@thomas> <86ec65b0-e4c6-46cd-a5f3-77a5d9947da0@www.fastmail.com> From: "Kinsella, Ray" Message-ID: Date: Fri, 23 Apr 2021 13:35:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <86ec65b0-e4c6-46cd-a5f3-77a5d9947da0@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AuthUser: mdr@ashroe.eu Subject: Re: [dpdk-dev] [PATCH v5 0/5] eal: enable global device syntax by default X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 23/04/2021 12:39, Gaëtan Rivet wrote: > On Fri, Apr 23, 2021, at 13:06, Kinsella, Ray wrote: >> >> >> On 14/04/2021 20:49, Thomas Monjalon wrote: >>> 13/04/2021 05:14, Xueming Li: >>>> Xueming Li (5): >>>> devargs: unify scratch buffer storage >>>> devargs: fix memory leak on parsing error >>>> kvargs: add get by key function >>>> bus: add device arguments name parsing API >>>> devargs: parse global device syntax >>> >>> The patch 4 adds a new callback in rte_bus. >>> I thought about it during the whole day and I don't see any good way >>> to merge it without breaking the ABI compatibility. >>> >>> Only first 3 patches are applied for now, thanks. >>> >> >> I took a look, I don't immediately see the concern. >> >> The new entry is at the end of the memory structure. >> The call back is internal and hidden behind the symbol rte_devargs_layers_parse. >> >> So will only be trigger by a rte_devargs_layers_parse of the same >> version of DPDK that introduce the new callback. >> >> Should be fine? >> > > It might have been an issue IMO with a structure exposed as an array, i.e. rte_eth_devices[]. > But I thought this kind of ABI break was the kind that would be accepted between two LTS. Very much depends on how it is done. New fields are ok in some circumstances, at first glance I thought one is ok. > The only potential risk is in using a new version librte_eal.so with an older librte_bus_xxx.so We don't account for or consider that, that would be an irrational environmnet. > But I think it is fair to expect installations to be internally consistent. > > Maybe we could have a runtime warning when loading mismatched versions Nope - that would be insanely complex. > (if there isn't one already) -- each librte_*.so could have an internal version stamp and alignment could > be checked through a constructor in each lib? >