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 9381BA04DB; Fri, 16 Oct 2020 16:15:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EEECA1D62A; Fri, 16 Oct 2020 16:15:37 +0200 (CEST) Received: from mta123.f1.k8.com.br (mta123.f1.k8.com.br [187.73.32.199]) by dpdk.org (Postfix) with ESMTP id A42911EDF1; Fri, 16 Oct 2020 15:55:23 +0200 (CEST) Received: from [192.168.86.43] (pool-108-49-43-207.bstnma.fios.verizon.net [108.49.43.207]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtpz.f1.k8.com.br (Postfix) with ESMTPSA id 95C2E160; Fri, 16 Oct 2020 13:55:15 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtpz.f1.k8.com.br 95C2E160 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digirati.com.br; s=default; t=1602856520; bh=rf1bG8QTc2tfECPWdZcsO+TF84pNWIpQqHqlqvPFNsk=; h=Subject:To:From:Date:Feedback-ID; b=Koh78HZpC6v2wCh0/bqsPPlRtHCZsF4ral1BKjdT+MBlYjanLfcV1fo+I1/MZbKDj go8VyxEsSAYpVotA78mY+8RTz1zbyeMeKvTmQvYCVr4lVbun1EkcoJTSXhL8SeDFZr OaPEHVwC1mTgTP1AxvHrSnhWx8XAxTPXL8tqS8sQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=k8.com.br; s=default; t=1602856520; bh=rf1bG8QTc2tfECPWdZcsO+TF84pNWIpQqHqlqvPFNsk=; h=Subject:To:From:Date:Feedback-ID; b=pYs+FXOVrnd302ISg3YE1G07vpXn7hXI+LYZDzmSnrzqP0VHkzY0ld19TJyde9qK0 6Rqqd27TcJskDV0VqTBGZemcdRwfA7wBPFchdNzXeXmiECWkSyriU0Gxk6zHY+y54x sXpd/+729b2VmcPvAotgMOHaL4bo3ktX7T67iKW0= To: Kevin Traynor , Honnappa Nagarahalli , "Medvedkin, Vladimir" , Ruifeng Wang , Bruce Richardson , Cody Doucette , Andre Nathan , Qiaobin Fu , "techboard@dpdk.org" , David Marchand , "thomas@monjalon.net" Cc: "dev@dpdk.org" , nd References: <20200907081518.46350-1-ruifeng.wang@arm.com> <48834549-00e9-b762-4915-9a2dd0e5fe1d@redhat.com> <6497770e-9d1c-97c3-3834-84bd96186836@digirati.com.br> <18c44f31-abc0-c0b5-c2fb-76d6166d5237@digirati.com.br> <9197371c-5e03-4852-d62a-6456f0b762f0@intel.com> <9647f80d-53c3-33aa-b6d0-301aef34ca0a@intel.com> <781ddbaf-cfed-bc90-cf6c-2b88bfda1202@digirati.com.br> <505d3e00-717b-25f8-ffea-d6108165a12a@intel.com> <3d74eba7-1b27-2b78-7ed3-de1307bdfddc@redhat.com> From: Michel Machado Organization: Digirati Internet LTDA. Message-ID: Date: Fri, 16 Oct 2020 09:55:12 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <3d74eba7-1b27-2b78-7ed3-de1307bdfddc@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-HN-S: bWljaGVsQGRpZ2lyYXRpLmNvbS5icg== X-HN-R: ZGF2aWQubWFyY2hhbmRAcmVkaGF0LmNvbQ== bWVuZ3hpYW5nMDgxMUBnbWFpbC5jb20= YW5kcmVAZGlnaXJhdGkuY29tLmJy ZG91Y2V0dGVAYnUuZWR1 SG9ubmFwcGEuTmFnYXJhaGFsbGlAYXJtLmNvbQ== a3RyYXlub3JAcmVkaGF0LmNvbQ== YnJ1Y2UucmljaGFyZHNvbkBpbnRlbC5jb20= UnVpZmVuZy5XYW5nQGFybS5jb20= dmxhZGltaXIubWVkdmVka2luQGludGVsLmNvbQ== dGhvbWFzQG1vbmphbG9uLm5ldA== dGVjaGJvYXJkQGRwZGsub3Jn Feedback-ID: MjAyMDEwMTY=:bWljaGVsQGRpZ2lyYXRpLmNvbS5icg==:ZGlnaXJhdGkuY29tLmJy:k8networks X-Mailman-Approved-At: Fri, 16 Oct 2020 16:15:36 +0200 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" >>>>> If the final choice is for not supporting a way to retrieve the >>>>> config information on the API, we'll look for a place to keep a copy >>>>> of the parameters in our code. >>>> IMO, this is not a performance critical path and it is not a difficult solution to >>> store these values in the application. My suggestion is to skip adding the API >>> and store the values in the application. >>>> Vladimir, what's your opinion? >>> >>> Agree. Global vars or part of a global configuration could be used here. >> Thank you. I think we are fine to go ahead with merging this patch. >> > > Michel, I know it's a bit of churn so not zero effort, but is that > solution workable for you? The change in DPDK would not be backported, > so gatekeeper code would only need an update on updating to use DPDK 20.11. It's workable. Thank you for organizing this discussion, Kevin. > P.S. As you are using DPDK 19.08, we should talk about DPDK LTS but > let's leave that for another thread :-) Sure.