Re: [dpdk-dev] [PATCH v4 5/6] net/ark: generalize meta data between FPGA and PMD

[Ed Czeck <ed.czeck@atomicrules.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.