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.w...@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 <ktray...@redhat.com> >> Sent: Wednesday, September 30, 2020 4:46 PM >> To: Ruifeng Wang <ruifeng.w...@arm.com>; Medvedkin, Vladimir >> <vladimir.medved...@intel.com>; Bruce Richardson >> <bruce.richard...@intel.com> >> Cc: dev@dpdk.org; Honnappa Nagarahalli >> <honnappa.nagaraha...@arm.com>; nd <n...@arm.com> >> 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 <vladimir.medved...@intel.com> >>>> Sent: Wednesday, September 16, 2020 12:28 AM >>>> To: Bruce Richardson <bruce.richard...@intel.com>; Ruifeng Wang >>>> <ruifeng.w...@arm.com> >>>> Cc: dev@dpdk.org; Honnappa Nagarahalli >>>> <honnappa.nagaraha...@arm.com>; nd <n...@arm.com> >>>> 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 <david.march...@redhat.com> >>>>>> Signed-off-by: Ruifeng Wang <ruifeng.w...@arm.com> >>>>>> Reviewed-by: Phil Yang <phil.y...@arm.com> >>>>>> --- >>>>>> lib/librte_lpm/rte_lpm.c | 152 >>>>>> +++++++++++++++++++++++--------------- >>>> - >>>>>> lib/librte_lpm/rte_lpm.h | 7 -- >>>>>> 2 files changed, 91 insertions(+), 68 deletions(-) >>>>>> >>>>> <snip> >>>>>> 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 >
