On 24 January 2017 at 16:51, Mike Holmes <mike.hol...@linaro.org> wrote: > On 24 January 2017 at 03:23, Savolainen, Petri (Nokia - FI/Espoo) > <petri.savolai...@nokia-bell-labs.com> wrote: >> >> >>> -----Original Message----- >>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Mike >>> Holmes >>> Sent: Monday, January 23, 2017 9:46 PM >>> To: lng-odp@lists.linaro.org >>> Subject: [lng-odp] [PATCH 0/4] introduce odph_api.h and clean up public >>> helper API >>> >>> Greatly reduce the proliferation of helper includes that every app needs >>> Make the public helper API very obvious >>> Fix recent inclusion of table APIs that were not in the helper include dir >>> and >>> were not exported during install. >> >> I think we should not do this (combine all helpers into an "API"). >> >> First, "odph_api.h" gives the impression that helper definitions are part of >> ODP API. > > I dont think it is confusing, but we can use odp_helper_ap.h rather > than odph_api and we do need a stable helper API so that apps are > portable > > Those are not, since e.g. Ethernet header struct definition is not > needed for HW acceleration > > Agree that is why they are helpers > > - it's needed (reused) for writing tests and examples. We could > decide to create and maintain an "ODP protocol suite" which would > follow RFC's closely and provide those struct definitions for tens of > protocols, all modes, options, etc included. Anyway, helper is not > that today. > > We can in future make better helper distinctions, but to date it has > all been in one, and it has been in a confusing state for a long time, > just look at the latest table stuff that was incorrectly accepted. > I can see OS_helpers, protocol_helpers, algorithm_helpers (tables) etc > all being their own mini lib that is ABI portable and installed once.
That is what I like "odph_api": i.e. <block>_<interface>. If ODP helpers is to be splitted into different parts, this kind of naming structure make sense. like future odph_ipheaders, odph_os ... Not sure about the "api" part, but that can be changed when the different blocks get clear. > >> >> Secondly, when application does this ... >> >> #include <odp/helper/eth.h> >> #include <odp/helper/icmp.h> >> #include <odp/helper/ip.h> >> >> ... instead of this. >> >> #include <odp/helper/odph_api.h> >> >> It is very easy to see what is happening, and what (extra) dependencies >> application has. > > The same for ODP, we need to pick one mechanism or another, I am happy > to agree if ODP also includes everything in parts, but having it in > one file makes the portable API for helper very concrete, it is need > to make the helpers be ABI compatible which is needed for the cloud. Agree with the consistency: if we accept a single odp_api.h why not the same for helpers? I am rather positive to these changes: they gather the different helper interfaces in one spot, making clearer what it the helper api and what is not. The different API "subblocks" are not clear here, that could be improved later. Christophe. > >> >> >> -Petri >> >> >> >> > > > > -- > Mike Holmes > Program Manager - Linaro Networking Group > Linaro.org │ Open source software for ARM SoCs > "Work should be fun and collaborative, the rest follows"
