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: Wed, 10 Mar 2021 16:53:12 -0500 [thread overview]
Message-ID: <CALZ3Gug9aSprEpReH-D0LKxK0jV9Xx9a4HgoxiZg64QdF9+NFg@mail.gmail.com> (raw)
In-Reply-To: <fc355ac6-1ee6-7e94-35fb-bdc41422292d@intel.com>
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
> >>
> >> <...>
> >>
> >>> 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.
>
> '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.
>
> 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.
Thanks,
Ed.
next prev parent reply other threads:[~2021-03-10 21:53 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 [this message]
2021-03-10 22:46 ` Ferruh Yigit
2021-03-11 13:15 ` Ed Czeck
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=CALZ3Gug9aSprEpReH-D0LKxK0jV9Xx9a4HgoxiZg64QdF9+NFg@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).