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

Ed Czeck ed.czeck at atomicrules.com
Thu Mar 11 14:15:54 CET 2021


On Wed, Mar 10, 2021 at 5:46 PM Ferruh Yigit <ferruh.yigit at 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 at 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 at 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 at 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.


More information about the dev mailing list