From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5778C433DB for ; Thu, 11 Mar 2021 13:16:08 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 284FA64FDE for ; Thu, 11 Mar 2021 13:16:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 284FA64FDE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atomicrules.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5818E22A4CD; Thu, 11 Mar 2021 14:16:07 +0100 (CET) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mails.dpdk.org (Postfix) with ESMTP id DCA6C22A34F for ; Thu, 11 Mar 2021 14:16:05 +0100 (CET) Received: by mail-lj1-f181.google.com with SMTP id r20so2079188ljk.4 for ; Thu, 11 Mar 2021 05:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atomicrules-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/0KeDN9Kx7ycC0ZkkV9yKTyzhOacvTI8YQmb/dIl4tw=; b=jjzwSSEMXHZagj6JfNwx+A3OvhKaSaHD2g/Lbdb9yHtj9Lxn/u7YZhwJ5cUUpnteRb Je8Ut9Vi0kCiRuBtXUIPvy3cAGYBBNDXAJQro1f2jV0I5gxqvkpsxmmipGPP3ZiyvOp9 lUJva/0cytUHMRelG9Dwnri2DVE9nZDLjFBa3M8E9WAyVs6riTGlmsSsymozcHd+ege7 zR8ZQ0/fJ0gmD9X++gxVVTMP7DAfqx6VI6fvID/NyTYvyih7aEAqgwt2dRezqtFTIkWb QUN3CaWh3HmOtlrk3SDIGUF/T/vSZgKRhqB4JtIyOzSB+4SB4vKTZKYNXGUsuR75WaVC PNWw== 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=/0KeDN9Kx7ycC0ZkkV9yKTyzhOacvTI8YQmb/dIl4tw=; b=HuxFHRqmQL6lTs0mz/rh8xUA83+PoVbsihKZ5t04rTPdIyZ/scwi0NAa/QgTUuSn6r 0KoNZJ28UGAAwbTsUAdy/6m5ya1vOpTIwEVoDUnTCxiYDEvs7f0xLaMyX/umLFAwkxz3 LF1nq4OdcA7E3PrBU5vheEdRv94BTDiFzqxloiiBu+UUGfe1DDjp0pZC752ZOLOAYB3p n+9fTNknEK+JZ5kGWlNT7SY98e92ukFFjyvsrbJw1AN29Tlc6rZhwTSOMuP1okEszDZu 96wXuEuOSolse6t1uGVkkLG5RX9lAIj/EkCypGfgLw+hFJSkMGQ1Z8j4qmuiCr7yb9G6 CKng== X-Gm-Message-State: AOAM531ju1M5mXUZf38yNGgMJcwEvfr/xdwWJrJlzPGlh+RJDvTLNjbB /cWYyMWcRDMLOu4fLxNYpn/4nuXrnq880DAAhUbJOw== X-Google-Smtp-Source: ABdhPJwC5oeFzM+Hf6AkbOsf7eks+OtyyCeqnM01n8wqrfGhJo9LknfhPqGQIU2TgrC2SQhttRQH+G6yVbb8bKYs6Ws= X-Received: by 2002:a05:651c:482:: with SMTP id s2mr4961221ljc.193.1615468565418; Thu, 11 Mar 2021 05:16:05 -0800 (PST) MIME-Version: 1.0 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> <9716b563-61db-d80d-a0a5-8c9b391ab395@intel.com> In-Reply-To: <9716b563-61db-d80d-a0a5-8c9b391ab395@intel.com> From: Ed Czeck Date: Thu, 11 Mar 2021 08:15:54 -0500 Message-ID: To: Ferruh Yigit Cc: dev@dpdk.org, Shepard Siegel , John Miller , Bruce Richardson Content-Type: text/plain; charset="UTF-8" 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 Wed, Mar 10, 2021 at 5:46 PM Ferruh Yigit wrote: > > 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 > >>>> > >>>> <...> > >>>> > >>>> 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. OK. I will submit another patch. Ed.