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