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 EDDFFA056A; Wed, 10 Mar 2021 23:46:29 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8B0D022A5D5; Wed, 10 Mar 2021 23:46:29 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 2623222A3A9 for ; Wed, 10 Mar 2021 23:46:27 +0100 (CET) IronPort-SDR: O5az+VbZvBQZQNEM1pB48ILZuHuHibm/2E58UlHf6uprff2ciPX5BWFPQNeuZlYdjeuiAi3mgC 3itL0/FWuVjQ== X-IronPort-AV: E=McAfee;i="6000,8403,9919"; a="175682687" X-IronPort-AV: E=Sophos;i="5.81,238,1610438400"; d="scan'208";a="175682687" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2021 14:46:25 -0800 IronPort-SDR: YgVbqDIT8jBk/eddfDrE4QwRIA1lNkfykzFKpvaAn7hXCRHr/jeYkKL4Rl9+nP1yLF0pPWDsEa t7QH+L1zQfUA== X-IronPort-AV: E=Sophos;i="5.81,238,1610438400"; d="scan'208";a="403862434" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.10.220]) ([10.252.10.220]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2021 14:46:24 -0800 To: Ed Czeck Cc: dev@dpdk.org, Shepard Siegel , John Miller , Bruce Richardson References: <20210304165637.24658-1-ed.czeck@atomicrules.com> <20210309160818.3553-1-ed.czeck@atomicrules.com> <20210309160818.3553-5-ed.czeck@atomicrules.com> <3f558b98-66d1-ce63-9ee0-90364cd51146@intel.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <9716b563-61db-d80d-a0a5-8c9b391ab395@intel.com> Date: Wed, 10 Mar 2021 22:46:20 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v4 5/6] net/ark: generalize meta data between FPGA and PMD 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 3/10/2021 9:53 PM, Ed Czeck wrote: > On Wed, Mar 10, 2021 at 11:44 AM Ferruh Yigit wrote: >> >> On 3/10/2021 3:02 PM, Ed Czeck wrote: >>> On Tue, Mar 9, 2021 at 12:36 PM Ferruh Yigit wrote: >>>> >>>> On 3/9/2021 4:08 PM, Ed Czeck wrote: >>>>> In this commit we generalize the movement of user-specified >>>>> meta data between mbufs and FPGA AXIS tuser fields using >>>>> user-defined hook functions. >>>>> >>>>> - Previous use of PMD dynfields are removed >>>>> - Hook function added to ark_user_ext >>>>> - Add hook function calls in Rx and Tx paths >>>>> - Update guide with example of hook function use >>>>> - Add release notes >>>>> >>>>> Signed-off-by: Ed Czeck >>>>> --- >>>>> v3: >>>>> - split function rename to separate commit >>>>> >>>>> v4: >>>>> - reorder patches renaming before adding >>>> >>>> <...> >>>> >>>>> diff --git a/drivers/net/ark/version.map b/drivers/net/ark/version.map >>>>> index 954bea679..4a76d1d52 100644 >>>>> --- a/drivers/net/ark/version.map >>>>> +++ b/drivers/net/ark/version.map >>>>> @@ -1,10 +1,3 @@ >>>>> DPDK_21 { >>>>> local: *; >>>>> }; >>>>> - >>>>> -EXPERIMENTAL { >>>>> - global: >>>>> - >>>>> - rte_pmd_ark_tx_userdata_dynfield_offset; >>>>> - rte_pmd_ark_rx_userdata_dynfield_offset; >>>>> -}; >>>>> >>>> >>>> Since there is no more public APIs by driver, I think it should stop installing >>>> the header, and remove it from 'meson.build' file, and remove the header from >>>> API documentation, 'doc/api/doxy-api-index.md'. >>>> >>>> I can see the header needs to be used by the extension developer, but that is >>>> still kind of PMD, the public headers are installed for the application developers. >>>> >>>> Still there is a desire to install the required headers for PMD developers, as >>>> far as I know Bruce is working on it, cc'ed. This header can be installed as >>>> part of that effort. >>>> >>>> Thanks, >>>> ferruh >>> >>> The function prototypes in the header are required by the extension >>> developer, hence >>> they need to be accessible in an installed file. Placing them in >>> rte_pmd-ark.h seems >>> like the existing solution. If there is a better location or solution >>> for publishing these >>> definitions, I have not found it yet. Please advise if I should change >>> this in some way. >>> >> >> I slightly remember we had same discussion before. >> >> Installed public headers are for application usage, but for ark PMD the header >> is for the PMD extension development. Currently there is no similar usage or >> requirement. > > The extension is part of the application as it executes in the same space and > has access to the same data as the application. > The function definitions are required as a sanity check for the > application, without > them (or with a stale version) we lose that ability. The access to > this header file > should be part of DPDK's exported interface, without it there is not a > standard include > location for this file. > I would argue the extension is part of PMD, not part of application. Extension is loaded by driver dynamically and provides callbacks that is called by PMD, transparent to the application. >> >> 'rte_pmd-ark.h' seems installed last release because of the public object it had >> for dynamic mbuf, which should be accessed by application. Now since those >> objects are gone and the content of the header is changed, it is not for >> applications anymore, hence I think it shouldn't be installed. >> >> As far as I can see the PMD extensions are very much related to the FPGA >> implementation, so the header is not for everyone to use to develop new code, I >> expect whoever needs the 'rte_pmd-ark.h' should have the source code already, >> instead of using the header from installed system path. > > The PMD extensions are the bridge between DPDK and the FPGA details; they > are not for everyone. The same argument can be made for the other 12 net drivers > which provide PMD public methods. We are attempting to have a standard way to > access these prototypes for the installed version of DPDK. > The PMD specific APIs are different, any application developer can be using them, if the developer wants the PMD specific feature with the trade of making their code non-portable. The extension callbacks is needed for whoever developing bit-streams for the FPGA. Of course the extension developer needs to include the header you are providing, but the standard way is for the public APIs not for this case. Do you expect anyone developing the drivers extensions without having the DPDK source code, if not the extension developer can copy the header. >> >> I think overall it is good to add doxygen comments and dpdk prefix to the >> extension symbols, but still they shouldn't be part of the API documentation. >> > Please consider my arguments and offer an alternative suggestion on how we can > provide these prototypes to our users. > As mentioned before there was a request to support out of tree driver support, I believe your use case matches more to this request, Bruce was looking to it and that solution can be the alternative solution you are looking for.