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 0B4DEA04B7; Tue, 13 Oct 2020 16:00:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A4A411DB22; Tue, 13 Oct 2020 15:53:29 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by dpdk.org (Postfix) with ESMTP id B12071DADB for ; Tue, 13 Oct 2020 15:53:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602597206; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OqWTMDBIvxh9jktrumQXm8lLfA5rYK4yypsexztBbvo=; b=d4SufLzsKxM/JdKPlEPYukqMi4Mjr08pKxsTWcDGIw+d5hXg4ugYqZ+TDfgFhQgOvJF9wK ECe7913mT1H+MzlszQbesywkRqZ5mubh4yo+6gbFHnPj2SYYYczM7M61flHgzY4uXuBJ2t nM4D/Dw1AsAepX+9tCsh/8FLaXAyZxs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-68-nOJcCt02Mk6Z2R47vqOupQ-1; Tue, 13 Oct 2020 09:53:22 -0400 X-MC-Unique: nOJcCt02Mk6Z2R47vqOupQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 942DB8030C0; Tue, 13 Oct 2020 13:53:20 +0000 (UTC) Received: from [10.33.36.94] (unknown [10.33.36.94]) by smtp.corp.redhat.com (Postfix) with ESMTP id B731519C71; Tue, 13 Oct 2020 13:53:17 +0000 (UTC) To: Ruifeng Wang , "Medvedkin, Vladimir" , Bruce Richardson , Michel Machado , Cody Doucette , Andre Nathan Cc: "dev@dpdk.org" , Honnappa Nagarahalli , nd References: <20200907081518.46350-1-ruifeng.wang@arm.com> <20200907081518.46350-3-ruifeng.wang@arm.com> <20200915160224.GA825@bricha3-MOBL.ger.corp.intel.com> <81eb8fde-cd4f-1df9-0ebb-05c902b30fe3@intel.com> From: Kevin Traynor Message-ID: <48834549-00e9-b762-4915-9a2dd0e5fe1d@redhat.com> Date: Tue, 13 Oct 2020 14:53:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=ktraynor@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data 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" Hi Gatekeeper maintainers (I think), fyi - there is a proposal to remove some members of a struct in DPDK LPM API that Gatekeeper is using [1]. It would be only from DPDK 20.11 but as it's an LTS I guess it would probably hit Debian in a few months. The full thread is here: http://inbox.dpdk.org/dev/20200907081518.46350-1-ruifeng.wang@arm.com/ Maybe you can take a look and tell us if they are needed in Gatekeeper or you can workaround it? thanks, Kevin. [1] https://github.com/AltraMayor/gatekeeper/blob/master/gt/lua_lpm.c#L235-L248 On 09/10/2020 07:54, Ruifeng Wang wrote: > >> -----Original Message----- >> From: Kevin Traynor >> Sent: Wednesday, September 30, 2020 4:46 PM >> To: Ruifeng Wang ; Medvedkin, Vladimir >> ; Bruce Richardson >> >> Cc: dev@dpdk.org; Honnappa Nagarahalli >> ; nd >> Subject: Re: [dpdk-dev] [PATCH 2/2] lpm: hide internal data >> >> On 16/09/2020 04:17, Ruifeng Wang wrote: >>> >>>> -----Original Message----- >>>> From: Medvedkin, Vladimir >>>> Sent: Wednesday, September 16, 2020 12:28 AM >>>> To: Bruce Richardson ; Ruifeng Wang >>>> >>>> Cc: dev@dpdk.org; Honnappa Nagarahalli >>>> ; nd >>>> Subject: Re: [PATCH 2/2] lpm: hide internal data >>>> >>>> Hi Ruifeng, >>>> >>>> On 15/09/2020 17:02, Bruce Richardson wrote: >>>>> On Mon, Sep 07, 2020 at 04:15:17PM +0800, Ruifeng Wang wrote: >>>>>> Fields except tbl24 and tbl8 in rte_lpm structure have no need to >>>>>> be exposed to the user. >>>>>> Hide the unneeded exposure of structure fields for better ABI >>>>>> maintainability. >>>>>> >>>>>> Suggested-by: David Marchand >>>>>> Signed-off-by: Ruifeng Wang >>>>>> Reviewed-by: Phil Yang >>>>>> --- >>>>>> lib/librte_lpm/rte_lpm.c | 152 >>>>>> +++++++++++++++++++++++--------------- >>>> - >>>>>> lib/librte_lpm/rte_lpm.h | 7 -- >>>>>> 2 files changed, 91 insertions(+), 68 deletions(-) >>>>>> >>>>> >>>>>> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h >>>>>> index 03da2d37e..112d96f37 100644 >>>>>> --- a/lib/librte_lpm/rte_lpm.h >>>>>> +++ b/lib/librte_lpm/rte_lpm.h >>>>>> @@ -132,17 +132,10 @@ struct rte_lpm_rule_info { >>>>>> >>>>>> /** @internal LPM structure. */ >>>>>> struct rte_lpm { >>>>>> - /* LPM metadata. */ >>>>>> - char name[RTE_LPM_NAMESIZE]; /**< Name of the lpm. */ >>>>>> - uint32_t max_rules; /**< Max. balanced rules per lpm. */ >>>>>> - uint32_t number_tbl8s; /**< Number of tbl8s. */ >>>>>> - struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH]; /**< >>>> Rule info table. */ >>>>>> - >>>>>> /* LPM Tables. */ >>>>>> struct rte_lpm_tbl_entry tbl24[RTE_LPM_TBL24_NUM_ENTRIES] >>>>>> __rte_cache_aligned; /**< LPM tbl24 table. */ >>>>>> struct rte_lpm_tbl_entry *tbl8; /**< LPM tbl8 table. */ >>>>>> - struct rte_lpm_rule *rules_tbl; /**< LPM rules. */ >>>>>> }; >>>>>> >>>>> >>>>> Since this changes the ABI, does it not need advance notice? >>>>> >>>>> [Basically the return value point from rte_lpm_create() will be >>>>> different, and that return value could be used by rte_lpm_lookup() >>>>> which as a static inline function will be in the binary and using >>>>> the old structure offsets.] >>>>> >>>> >>>> Agree with Bruce, this patch breaks ABI, so it can't be accepted >>>> without prior notice. >>>> >>> So if the change wants to happen in 20.11, a deprecation notice should >>> have been added in 20.08. >>> I should have added a deprecation notice. This change will have to wait for >> next ABI update window. >>> >> >> Do you plan to extend? or is this just speculative? > It is speculative. > >> >> A quick scan and there seems to be several projects using some of these >> members that you are proposing to hide. e.g. BESS, NFF-Go, DPVS, >> gatekeeper. I didn't look at the details to see if they are really needed. >> >> Not sure how much notice they'd need or if they update DPDK much, but I >> think it's worth having a closer look as to how they use lpm and what the >> impact to them is. > Checked the projects listed above. BESS, NFF-Go and DPVS don't access the members to be hided. > They will not be impacted by this patch. > But Gatekeeper accesses the rte_lpm internal members that to be hided. Its compilation will be broken with this patch. > >> >>> Thanks. >>> Ruifeng >>>>>> /** LPM RCU QSBR configuration structure. */ >>>>>> -- >>>>>> 2.17.1 >>>>>> >>>> >>>> -- >>>> Regards, >>>> Vladimir >