From: Ed Czeck <ed.czeck@atomicrules.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org, Shepard Siegel <shepard.siegel@atomicrules.com>,
John Miller <john.miller@atomicrules.com>,
Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] [PATCH v4 5/6] net/ark: generalize meta data between FPGA and PMD
Date: Thu, 11 Mar 2021 08:15:54 -0500 [thread overview]
Message-ID: <CALZ3GuiFjU1ux43quVpTrSGo3Cx+6SEvcbJGQqhhyO8YPjQT4A@mail.gmail.com> (raw)
In-Reply-To: <9716b563-61db-d80d-a0a5-8c9b391ab395@intel.com>
On Wed, Mar 10, 2021 at 5:46 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> On 3/10/2021 9:53 PM, Ed Czeck wrote:
> > On Wed, Mar 10, 2021 at 11:44 AM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >>
> >> On 3/10/2021 3:02 PM, Ed Czeck wrote:
> >>> On Tue, Mar 9, 2021 at 12:36 PM Ferruh Yigit <ferruh.yigit@intel.com> 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 <ed.czeck@atomicrules.com>
> >>>>> ---
> >>>>> 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.
next prev parent reply other threads:[~2021-03-11 13:16 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-04 16:56 [dpdk-dev] [PATCH v1 1/5] net/ark: update pkt director initial state Ed Czeck
2021-03-04 16:56 ` [dpdk-dev] [PATCH v1 2/5] net/ark: refactor Rx buffer recovery Ed Czeck
2021-03-04 16:56 ` [dpdk-dev] [PATCH v1 3/5] net/ark: update internal structs to reflect FPGA updates Ed Czeck
2021-03-04 16:56 ` [dpdk-dev] [PATCH v1 4/5] net/ark: generalize meta data between FPGA and PMD Ed Czeck
2021-03-04 16:56 ` [dpdk-dev] [PATCH v1 5/5] net/ark: localize internal packet generator code Ed Czeck
2021-03-04 20:33 ` [dpdk-dev] [PATCH v2 1/5] net/ark: update pkt director initial state Ed Czeck
2021-03-04 20:33 ` [dpdk-dev] [PATCH v2 2/5] net/ark: refactor Rx buffer recovery Ed Czeck
2021-03-04 20:33 ` [dpdk-dev] [PATCH v2 3/5] net/ark: update internal structs to reflect FPGA updates Ed Czeck
2021-03-05 15:38 ` Ferruh Yigit
2021-03-04 20:33 ` [dpdk-dev] [PATCH v2 4/5] net/ark: generalize meta data between FPGA and PMD Ed Czeck
2021-03-05 15:31 ` Ferruh Yigit
2021-03-04 20:33 ` [dpdk-dev] [PATCH v2 5/5] net/ark: localize internal packet generator code Ed Czeck
2021-03-08 22:29 ` [dpdk-dev] [PATCH v3 1/6] net/ark: update pkt director initial state Ed Czeck
2021-03-08 22:29 ` [dpdk-dev] [PATCH v3 2/6] net/ark: refactor Rx buffer recovery Ed Czeck
2021-03-08 22:29 ` [dpdk-dev] [PATCH v3 3/6] net/ark: update internal structs to reflect FPGA updates Ed Czeck
2021-03-09 11:32 ` Ferruh Yigit
2021-03-08 22:29 ` [dpdk-dev] [PATCH v3 4/6] net/ark: generalize meta data between FPGA and PMD Ed Czeck
2021-03-08 22:29 ` [dpdk-dev] [PATCH v3 5/6] net/ark: cleanup and document ark dynamic extansion Ed Czeck
2021-03-09 11:43 ` Ferruh Yigit
2021-03-08 22:29 ` [dpdk-dev] [PATCH v3 6/6] net/ark: localize internal packet generator code Ed Czeck
2021-03-09 16:08 ` [dpdk-dev] [PATCH v4 1/6] net/ark: update pkt director initial state Ed Czeck
2021-03-09 16:08 ` [dpdk-dev] [PATCH v4 2/6] net/ark: refactor Rx buffer recovery Ed Czeck
2021-03-09 16:08 ` [dpdk-dev] [PATCH v4 3/6] net/ark: update internal structs to reflect FPGA updates Ed Czeck
2021-03-09 16:08 ` [dpdk-dev] [PATCH v4 4/6] net/ark: cleanup ark dynamic extension interface Ed Czeck
2021-03-09 17:50 ` Ferruh Yigit
2021-03-10 15:11 ` Ed Czeck
2021-03-10 16:29 ` Ferruh Yigit
2021-03-09 16:08 ` [dpdk-dev] [PATCH v4 5/6] net/ark: generalize meta data between FPGA and PMD Ed Czeck
2021-03-09 17:36 ` Ferruh Yigit
2021-03-10 15:02 ` Ed Czeck
2021-03-10 16:44 ` Ferruh Yigit
2021-03-10 21:53 ` Ed Czeck
2021-03-10 22:46 ` Ferruh Yigit
2021-03-11 13:15 ` Ed Czeck [this message]
2021-03-09 16:08 ` [dpdk-dev] [PATCH v4 6/6] net/ark: localize internal packet generator code Ed Czeck
2021-03-18 17:36 ` [dpdk-dev] [PATCH v5 1/6] net/ark: update pkt director initial state Ed Czeck
2021-03-18 17:36 ` [dpdk-dev] [PATCH v5 2/6] net/ark: refactor Rx buffer recovery Ed Czeck
2021-03-18 17:36 ` [dpdk-dev] [PATCH v5 3/6] net/ark: update internal structs to reflect FPGA updates Ed Czeck
2021-03-18 17:36 ` [dpdk-dev] [PATCH v5 4/6] net/ark: cleanup ark dynamic extension interface Ed Czeck
2021-03-18 17:36 ` [dpdk-dev] [PATCH v5 5/6] net/ark: generalize meta data between FPGA and PMD Ed Czeck
2021-03-18 17:37 ` [dpdk-dev] [PATCH v5 6/6] net/ark: localize internal packet generator code Ed Czeck
2021-03-22 15:59 ` [dpdk-dev] [PATCH v5 1/6] net/ark: update pkt director initial state Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALZ3GuiFjU1ux43quVpTrSGo3Cx+6SEvcbJGQqhhyO8YPjQT4A@mail.gmail.com \
--to=ed.czeck@atomicrules.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=john.miller@atomicrules.com \
--cc=shepard.siegel@atomicrules.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).