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 03FF0A04DD; Thu, 22 Oct 2020 17:14:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DC6F55AA0; Thu, 22 Oct 2020 17:14:33 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by dpdk.org (Postfix) with ESMTP id AA40D5A9C for ; Thu, 22 Oct 2020 17:14:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603379670; 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: in-reply-to:in-reply-to:references:references; bh=VXoefcUAQiq21HAcf2YEyhP15c+M2lEwbbhGEHvDUSw=; b=ABP//0WU6tR3AEuIxP5Kq4etIq66K6ZD9PCKyOOWpFj4Jy+kJPBJdBoPcnoAvFaNUYYUrB /fJP22BZSFOvo8LfsbQj6KNtE1AceUxFnnOLXtNhqMeXi2J0Cg1U+RlwadZgw5gPVpHpT1 5FQQkUfO1PHjQYGc/8S6bgfWZ1A3W8I= Received: from mail-vs1-f72.google.com (mail-vs1-f72.google.com [209.85.217.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-523-fr9F9MHUP22yebVuEGvV9Q-1; Thu, 22 Oct 2020 11:14:28 -0400 X-MC-Unique: fr9F9MHUP22yebVuEGvV9Q-1 Received: by mail-vs1-f72.google.com with SMTP id g5so459679vsg.14 for ; Thu, 22 Oct 2020 08:14:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VXoefcUAQiq21HAcf2YEyhP15c+M2lEwbbhGEHvDUSw=; b=FXpTf7jLvsQmVy3CcqO4SWbQBhQ+/G4UXXTRMpldr0LK6G5LQ+ge0ryA/drDh5r9F3 NKSsS/hEvkwFKqFLC4mfrrtfPj5bQFkuCPuqqBeCPkezg3LP2ntagWEV2QDKB13ktDfM SfodUKFlBm2kydoHQdk74TBzpXT/JLYjKgYG3rYr3/SrOmh0YnDOxpj/uPGaObK+PfYf zGenm8jQlRXNQIZhfMvDfPpAQKmhgQklhnYitnGwfqiyO2Vzo3PcZn/mnEl4dm3NKzmu 3uuTdigvrPgAaE+F7fj9GN4HbgTuC2plneWSO1lyc4sJQ9l1hn2+XyAopr4DKYWVl1Qs wBSg== X-Gm-Message-State: AOAM530hQMVWhfdnbRxk+q6XbhKoaNtCeWN40I/iiqsSTc+HZKzlQfuP kClIDquUAAkHYOnvj0W2Y1IZcti3Ze0lRPr1zl4HmwrzheESVL9DcsUBqA3abeUn/xpKS5Y/CZ/ hi4D6JoBx7cNRQHB5nIs= X-Received: by 2002:a9f:2e11:: with SMTP id t17mr1653560uaj.126.1603379666681; Thu, 22 Oct 2020 08:14:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyN/eJOnBzP2JdbE9sy47SN4PusjjJTZ6yEl13eB29TC8vzvbK8u0BFn+qBN8LHnricFacY8h1CSBJvy2NgB70= X-Received: by 2002:a9f:2e11:: with SMTP id t17mr1653518uaj.126.1603379666376; Thu, 22 Oct 2020 08:14:26 -0700 (PDT) MIME-Version: 1.0 References: <20200907081518.46350-1-ruifeng.wang@arm.com> <20201021030211.36381-1-ruifeng.wang@arm.com> <20201021030211.36381-3-ruifeng.wang@arm.com> In-Reply-To: <20201021030211.36381-3-ruifeng.wang@arm.com> From: David Marchand Date: Thu, 22 Oct 2020 17:14:13 +0200 Message-ID: To: Ruifeng Wang Cc: Bruce Richardson , Vladimir Medvedkin , dev , Honnappa Nagarahalli , nd , Kevin Traynor , Thomas Monjalon Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 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" On Wed, Oct 21, 2020 at 5:02 AM Ruifeng Wang wrote: > diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c > index 51a0ae578..88d31df6d 100644 > --- a/lib/librte_lpm/rte_lpm.c > +++ b/lib/librte_lpm/rte_lpm.c > @@ -42,9 +42,17 @@ enum valid_flag { > > /** @internal LPM structure. */ > struct __rte_lpm { > - /* LPM metadata. */ > + /* Exposed LPM data. */ > struct rte_lpm 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. */ > + /**< Rule info table. */ > + struct rte_lpm_rule_info rule_info[RTE_LPM_MAX_DEPTH]; > + struct rte_lpm_rule *rules_tbl; /**< LPM rules. */ - We hide the rules, is there a reason to keep struct rte_lpm_rule_info and struct rte_lpm_rule exposed? - Rather than have translations lpm -> i_lpm, in many places of this library, we should translate only in the functions exposed to the user. Besides, it is a bit hard to read between internal_lpm and i_lpm, I would adopt a single i_lpm convention for the whole file. I went and tried to do it (big search and replace + build tests, no runtime check though). This results in: https://github.com/david-marchand/dpdk/commit/4e61f0ce7cf2ac472565d3c6aa5bb78ffb8f70c9 What do you think? -- David Marchand