| Message ID | 1452285014-60320-3-git-send-email-christophe.milard@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 11 January 2016 at 03:54, Savolainen, Petri (Nokia - FI/Espoo) < petri.savolainen@nokia.com> wrote: > CC’d the list again. > > > > > > *From:* EXT Christophe Milard [mailto:christophe.milard@linaro.org] > *Sent:* Monday, January 11, 2016 10:29 AM > *To:* Savolainen, Petri (Nokia - FI/Espoo) > *Subject:* Re: [API-NEXT RFC 02/31] api: introducing the driver api > definition file > > > > > > On 11 January 2016 at 09:12, Savolainen, Petri (Nokia - FI/Espoo) < > petri.savolainen@nokia.com> wrote: > > > > > -----Original Message----- > > From: EXT Christophe Milard [mailto:christophe.milard@linaro.org] > > Sent: Friday, January 08, 2016 10:30 PM > > To: anders.roxell@linaro.org; mike.holmes@linaro.org; > > stuart.haslam@linaro.org; maxim.uvarov@linaro.org; > > bill.fischofer@linaro.org; petri.savolainen@linaro.org; > > edavis@broadcom.com > > Cc: lng-odp@lists.linaro.org; Christophe Milard > > Subject: [API-NEXT RFC 02/31] api: introducing the driver api definition > > file > > > > include/odp.h defines the ODP-application API (as before). > > include/odp_driver.h defines the new driver API. > > Note that the two APIs (application API and driver API) are partly > > overlapping: Some files such as byteorder.h, sync.h, hints.h... needs > > obviously to be part of both APIs. > > > > Signed-off-by: Christophe Milard <christophe.milard@linaro.org> > > --- > > include/odp.h | 2 +- > > include/odp_driver.h | 34 ++++++++++++++++++++++++++++++++++ > > 2 files changed, 35 insertions(+), 1 deletion(-) > > create mode 100644 include/odp_driver.h > > > > diff --git a/include/odp.h b/include/odp.h > > index 4a93c23..1c880df 100644 > > --- a/include/odp.h > > +++ b/include/odp.h > > @@ -7,7 +7,7 @@ > > /** > > * @file > > * > > - * The OpenDataPlane API > > + * The OpenDataPlane API to applications > > This addition is not needed, since API ("Application Programming > Interface") should be always defined for applications. > > > > OK > > > > > > > * > > */ > > > > diff --git a/include/odp_driver.h b/include/odp_driver.h > > new file mode 100644 > > index 0000000..b59f7df > > --- /dev/null > > +++ b/include/odp_driver.h > > @@ -0,0 +1,34 @@ > > +/* Copyright (c) 2015, Linaro Limited > > + * All rights reserved > > + * > > + * SPDX-License-Identifier: BSD-3-Clause > > + */ > > + > > +/** > > + * @file > > + * > > + * The OpenDataPlane API to NIC drivers > > > To keep it simple, ODP API should always point towards applications. This > can be named e.g. "ODP Driver Interface" (ODP-DI ?). It's an interface to > connect drivers to ODP implementations, not an interface to develop > applications (that are NIC drivers, etc). > > All driver interface data types and calls should be also prefixed with > odpdrv_, odpd_, odpdi_ or something similar (other than odp_), so that it's > clear which definitions belong to the API and which to the driver interface. > > > > That was my original intemtion, but how would you then handle the > overlaping situation of these programming interfaces? shmem, byte order, > barriers, locks, hints ... Many API things (according to your terminology) > would also be part of the DI... Would you then alias all these > functions...? > > > > > > If driver interface needs some definitions from API side, then we include > those from the API (and maintain those in sync with API) . New / additional > definitions are prefixed with e.g. odpdi_. > odpdi_ would be clearer written as odpdr_or maybe longer but clearer odpdrv_ > Driver API can consist of a bunch of odp_ defientions (re-used from API > side) and odpdi_ definitions (only for drivers). Driver interface may have > its own version numbering. An API change in those reused calls/definitions > would also bump the driver interface version. We should select carefully > which definitions and calls are really needed (or are useful) on driver > side and include only those, which means that some of the headers > (mentioned under) may need to be split into API only vs. API + DI parts. > > > > > > Pseudo code for odp/include/odp/driver/odp_driver.h > This needs to be odp/include/odp_driver.h Why complicate the structure and place the interface for the drivers down deep, lets just put all the interfaces under odp/include it is then nice and simple with all public interfaces found at the same level. The structure of an interfaces includes also then mirrors each other and the includes listed below do fall out as written. There will be very little chance of confusion by app writers. > > > #include <api/shared_memory.h> > #include <api/std_types.h> > #include < api/byteorder.h> > > #include <api/align.h> > #include <api/sync.h> > #include <api/hints.h> > #include <api/time.h> > > > > #include <driver/dma.h> > > #include <driver/pci.h> > > #include <driver/nic.h> > > … > > > > > > -Petri > > > > > > > > > -Petri > > > > > + * > > + */ > > + > > +#ifndef ODP_DRIVER_H_ > > +#define ODP_DRIVER_H_ > > + > > +#ifdef __cplusplus > > +extern "C" { > > +#endif > > + > > +#include <odp/shared_memory.h> > > +#include <odp/std_types.h> > > +#include <odp/byteorder.h> > > +#include <odp/dma.h> > > +#include <odp/align.h> > > +#include <odp/sync.h> > > +#include <odp/hints.h> > > +#include <odp/time.h> > > + > > +#ifdef __cplusplus > > +} > > +#endif > > + > > +#endif /*ODP_DRIVER_H_*/ > > -- > > 2.1.4 > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
Confused: Are we talking about aliasing all functions XXX to api_XXX() and/or drv_XXX(), i.e. some sort of facading, or are we still talking about having the driver interface using drv_XXX() and api_YYY()? 1) Facading: Facading make sense: it is clearly defined. But is comes with extra complexity: All external symbols would have to be defined N+1 time where N is the number of interface the symbol "belongs to". for instance: today's odp_shm_reserve() would be defined as: _odp_shm_reserve() ,with the initial underscore, in some internal file. It would then be aliased as api_shm_reserve() for the application interface and dpi_shm_reserve() for the driver interface. The driver interface would ONLY consist of dpi_* symbols. odp_driver.h would only includes dpi_* files which should be gathered in a specific (dpi) directory The application interface would ONLY consist of api_* symbols. odp_api.h would only includes api_* files which should be gathered in a specific (api) directory The price is more files and symbols and an extra indirection for each function. I am working on such a proposal right now. should I continue? 2) Mixing: The second alternative is the one depicted by Petri: We let API function as today, and add driver specific symbols in a separate directory. "driver.h" would include both odp_* symbols (those common to both interfaces) and dpi_* symbols (driver interface only). I have to admit that I cannot see that scale: As explained in a previous mail, what happens when extra interfaces are added? Or when a function originally thought for drivers is needed for the application side? 3) Defining the interfaces by .h files: The third alternative I can think of is the one presented in the Pach serie, where interfaces are defined by the include file rather than by a directory. It is well defined, scales, but does not present 1 directory per interface. Alternative 3 did not seem popular. Do we agree on 1? Or is 2 still actual? Christophe. On 13 January 2016 at 03:58, Mike Holmes <mike.holmes@linaro.org> wrote: > > > On 11 January 2016 at 03:54, Savolainen, Petri (Nokia - FI/Espoo) < > petri.savolainen@nokia.com> wrote: > >> CC’d the list again. >> >> >> >> >> >> *From:* EXT Christophe Milard [mailto:christophe.milard@linaro.org] >> *Sent:* Monday, January 11, 2016 10:29 AM >> *To:* Savolainen, Petri (Nokia - FI/Espoo) >> *Subject:* Re: [API-NEXT RFC 02/31] api: introducing the driver api >> definition file >> >> >> >> >> >> On 11 January 2016 at 09:12, Savolainen, Petri (Nokia - FI/Espoo) < >> petri.savolainen@nokia.com> wrote: >> >> >> >> > -----Original Message----- >> > From: EXT Christophe Milard [mailto:christophe.milard@linaro.org] >> > Sent: Friday, January 08, 2016 10:30 PM >> > To: anders.roxell@linaro.org; mike.holmes@linaro.org; >> > stuart.haslam@linaro.org; maxim.uvarov@linaro.org; >> > bill.fischofer@linaro.org; petri.savolainen@linaro.org; >> > edavis@broadcom.com >> > Cc: lng-odp@lists.linaro.org; Christophe Milard >> > Subject: [API-NEXT RFC 02/31] api: introducing the driver api definition >> > file >> > >> > include/odp.h defines the ODP-application API (as before). >> > include/odp_driver.h defines the new driver API. >> > Note that the two APIs (application API and driver API) are partly >> > overlapping: Some files such as byteorder.h, sync.h, hints.h... needs >> > obviously to be part of both APIs. >> > >> > Signed-off-by: Christophe Milard <christophe.milard@linaro.org> >> > --- >> > include/odp.h | 2 +- >> > include/odp_driver.h | 34 ++++++++++++++++++++++++++++++++++ >> > 2 files changed, 35 insertions(+), 1 deletion(-) >> > create mode 100644 include/odp_driver.h >> > >> > diff --git a/include/odp.h b/include/odp.h >> > index 4a93c23..1c880df 100644 >> > --- a/include/odp.h >> > +++ b/include/odp.h >> > @@ -7,7 +7,7 @@ >> > /** >> > * @file >> > * >> > - * The OpenDataPlane API >> > + * The OpenDataPlane API to applications >> >> This addition is not needed, since API ("Application Programming >> Interface") should be always defined for applications. >> >> >> >> OK >> >> >> >> >> >> > * >> > */ >> > >> > diff --git a/include/odp_driver.h b/include/odp_driver.h >> > new file mode 100644 >> > index 0000000..b59f7df >> > --- /dev/null >> > +++ b/include/odp_driver.h >> > @@ -0,0 +1,34 @@ >> > +/* Copyright (c) 2015, Linaro Limited >> > + * All rights reserved >> > + * >> > + * SPDX-License-Identifier: BSD-3-Clause >> > + */ >> > + >> > +/** >> > + * @file >> > + * >> > + * The OpenDataPlane API to NIC drivers >> >> >> To keep it simple, ODP API should always point towards applications. This >> can be named e.g. "ODP Driver Interface" (ODP-DI ?). It's an interface to >> connect drivers to ODP implementations, not an interface to develop >> applications (that are NIC drivers, etc). >> >> All driver interface data types and calls should be also prefixed with >> odpdrv_, odpd_, odpdi_ or something similar (other than odp_), so that it's >> clear which definitions belong to the API and which to the driver interface. >> >> >> >> That was my original intemtion, but how would you then handle the >> overlaping situation of these programming interfaces? shmem, byte order, >> barriers, locks, hints ... Many API things (according to your terminology) >> would also be part of the DI... Would you then alias all these >> functions...? >> >> >> >> >> >> If driver interface needs some definitions from API side, then we include >> those from the API (and maintain those in sync with API) . New / additional >> definitions are prefixed with e.g. odpdi_. >> > > odpdi_ would be clearer written as odpdr_or maybe longer but clearer > odpdrv_ > > >> Driver API can consist of a bunch of odp_ defientions (re-used from API >> side) and odpdi_ definitions (only for drivers). Driver interface may have >> its own version numbering. An API change in those reused calls/definitions >> would also bump the driver interface version. We should select carefully >> which definitions and calls are really needed (or are useful) on driver >> side and include only those, which means that some of the headers >> (mentioned under) may need to be split into API only vs. API + DI parts. >> >> >> >> >> >> Pseudo code for odp/include/odp/driver/odp_driver.h >> > > This needs to be odp/include/odp_driver.h Why complicate the structure > and place the interface for the drivers down deep, lets just put all the > interfaces under odp/include it is then nice and simple with all public > interfaces found at the same level. The structure of an interfaces includes > also then mirrors each other and the includes listed below do fall out as > written. There will be very little chance of confusion by app writers. > > > >> >> >> #include <api/shared_memory.h> >> #include <api/std_types.h> >> #include < api/byteorder.h> >> >> #include <api/align.h> >> #include <api/sync.h> >> #include <api/hints.h> >> #include <api/time.h> >> >> >> >> #include <driver/dma.h> >> >> #include <driver/pci.h> >> >> #include <driver/nic.h> >> >> … >> >> >> >> >> >> -Petri >> >> >> >> >> >> >> >> >> -Petri >> >> >> >> > + * >> > + */ >> > + >> > +#ifndef ODP_DRIVER_H_ >> > +#define ODP_DRIVER_H_ >> > + >> > +#ifdef __cplusplus >> > +extern "C" { >> > +#endif >> > + >> > +#include <odp/shared_memory.h> >> > +#include <odp/std_types.h> >> > +#include <odp/byteorder.h> >> > +#include <odp/dma.h> >> > +#include <odp/align.h> >> > +#include <odp/sync.h> >> > +#include <odp/hints.h> >> > +#include <odp/time.h> >> > + >> > +#ifdef __cplusplus >> > +} >> > +#endif >> > + >> > +#endif /*ODP_DRIVER_H_*/ >> > -- >> > 2.1.4 >> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs > > >
On 13 January 2016 at 11:31, Savolainen, Petri (Nokia - FI/Espoo) < petri.savolainen@nokia.com> wrote: > > > ODP API (odp.h and everything you can see through that) does not change at > all due to the introduction of driver interface. You may need to add some > parameters or functions, but it should be very minimal since driver > interface is part of the internal structure of an implementation (and may > not even be there). > That is probably the first thing we should agree on (I actually though we already did). Are the driver part of ODP or external to ODP? My opinion is that they are external to ODP. Mainly because they will be developed separately by external companies (NIC constructor). If this is the case the interface to the driver should very clear, well defined and documented. Some are even talking for having the drivers on a separate repo... > > > Driver interface can be composed from calls / definitions that are all > prefixed with odpdrv_ or mixture of odp_ and odpdrv_. In case of mixture, > you’d need to state that each odp_ definition is exactly the same as in the > API (follows API development). This would make sense on those small things > that are well defined and static (e.g. ODP_CACHE_LINE_SIZE). More complex > definitions have a risk that API spec is written from application point of > view (as it should), but driver is part of implementation. What > implementation can or cannot be guaranteed to the application, may not > always hold for one part of the implementation (the driver). So, the common > spec may not always hold, or may start to deviate. So, the more driver > interface is defined only for drivers (odpdrv_xxx), the better. > It seems that we agree on the fact that we'd like the API and the Driver interface to overlap as little as possible. Saddly, I see quite many things that drivers will need which are common between the interfaces: for instance: atomic, barriers, locks, shared memory, time (for small wait), byteorder, hints, thread-IDs... > > > Now, the big question is how much the same definitions are needed on > driver and application side. E.g. is it OK that driver creates (or knows > about) SHM regions? Or should it just request a lists of (void*) pointers. > If driver needs memory, it could ask it through a odpdrv_ call like this > > > > Int odpdrv_give_me_memory(uint64_t this_many_bytes, int > max_this_many_chunks, …, odpdrv_memory_object_t table_for_output[]) > > > > > > The more ODP specific functionality is on the implementation side the > better. The less ODP API concepts on the driver interface the better. > Driver interface should consist of pointers, lengths, flags … instead of > shms, pools, queues, … Odp_packet_t is likely an exception but again driver > interface could split the responsibility of filling packet metadata between > driver and implementation (drv fills x, y, z – implementation fills the > rest). > There is no need to expose ODP packets as such to the drivers. In the proposed implementation, drivers uses a new object called NIC segments instead. Yes, they can match the packets. And the last segment of a received packet would have attributes similar to packet attributes. Christophe. > > > > > -Petri > > > > > > > > *From:* EXT Christophe Milard [mailto:christophe.milard@linaro.org] > *Sent:* Wednesday, January 13, 2016 10:23 AM > *To:* Mike Holmes > *Cc:* Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org > *Subject:* Re: [lng-odp] [API-NEXT RFC 02/31] api: introducing the driver > api definition file > > > > Confused: Are we talking about aliasing all functions XXX to api_XXX() > and/or drv_XXX(), i.e. some sort of facading, or are we still talking about > having the driver interface using drv_XXX() and api_YYY()? > > > > 1) Facading: > > Facading make sense: it is clearly defined. But is comes with extra > complexity: All external symbols would have to be defined N+1 time where N > is the number of interface the symbol "belongs to". > > for instance: today's odp_shm_reserve() would be defined as: > _odp_shm_reserve() ,with the initial underscore, in some internal file. It > would then be aliased as api_shm_reserve() for the application interface > and dpi_shm_reserve() for the driver interface. > > The driver interface would ONLY consist of dpi_* symbols. odp_driver.h > would only includes dpi_* files which should be gathered in a specific > (dpi) directory > > The application interface would ONLY consist of api_* symbols. odp_api.h > would only includes api_* files which should be gathered in a specific > (api) directory > > The price is more files and symbols and an extra indirection for each > function. > > I am working on such a proposal right now. should I continue? > > > > 2) Mixing: > > The second alternative is the one depicted by Petri: We let API function > as today, and add driver specific symbols in a separate directory. > "driver.h" would include both odp_* symbols (those common to both > interfaces) and dpi_* symbols (driver interface only). I have to admit that > I cannot see that scale: As explained in a previous mail, what happens when > extra interfaces are added? Or when a function originally thought for > drivers is needed for the application side? > > > > 3) Defining the interfaces by .h files: > > The third alternative I can think of is the one presented in the Pach > serie, where interfaces are defined by the include file rather than by a > directory. It is well defined, scales, but does not present 1 directory per > interface. > > > > Alternative 3 did not seem popular. Do we agree on 1? Or is 2 still actual? > > > > Christophe. > > > > > > > > On 13 January 2016 at 03:58, Mike Holmes <mike.holmes@linaro.org> wrote: > > > > > > On 11 January 2016 at 03:54, Savolainen, Petri (Nokia - FI/Espoo) < > petri.savolainen@nokia.com> wrote: > > CC’d the list again. > > > > > > *From:* EXT Christophe Milard [mailto:christophe.milard@linaro.org] > *Sent:* Monday, January 11, 2016 10:29 AM > *To:* Savolainen, Petri (Nokia - FI/Espoo) > *Subject:* Re: [API-NEXT RFC 02/31] api: introducing the driver api > definition file > > > > > > On 11 January 2016 at 09:12, Savolainen, Petri (Nokia - FI/Espoo) < > petri.savolainen@nokia.com> wrote: > > > > > -----Original Message----- > > From: EXT Christophe Milard [mailto:christophe.milard@linaro.org] > > Sent: Friday, January 08, 2016 10:30 PM > > To: anders.roxell@linaro.org; mike.holmes@linaro.org; > > stuart.haslam@linaro.org; maxim.uvarov@linaro.org; > > bill.fischofer@linaro.org; petri.savolainen@linaro.org; > > edavis@broadcom.com > > Cc: lng-odp@lists.linaro.org; Christophe Milard > > Subject: [API-NEXT RFC 02/31] api: introducing the driver api definition > > file > > > > include/odp.h defines the ODP-application API (as before). > > include/odp_driver.h defines the new driver API. > > Note that the two APIs (application API and driver API) are partly > > overlapping: Some files such as byteorder.h, sync.h, hints.h... needs > > obviously to be part of both APIs. > > > > Signed-off-by: Christophe Milard <christophe.milard@linaro.org> > > --- > > include/odp.h | 2 +- > > include/odp_driver.h | 34 ++++++++++++++++++++++++++++++++++ > > 2 files changed, 35 insertions(+), 1 deletion(-) > > create mode 100644 include/odp_driver.h > > > > diff --git a/include/odp.h b/include/odp.h > > index 4a93c23..1c880df 100644 > > --- a/include/odp.h > > +++ b/include/odp.h > > @@ -7,7 +7,7 @@ > > /** > > * @file > > * > > - * The OpenDataPlane API > > + * The OpenDataPlane API to applications > > This addition is not needed, since API ("Application Programming > Interface") should be always defined for applications. > > > > OK > > > > > > > * > > */ > > > > diff --git a/include/odp_driver.h b/include/odp_driver.h > > new file mode 100644 > > index 0000000..b59f7df > > --- /dev/null > > +++ b/include/odp_driver.h > > @@ -0,0 +1,34 @@ > > +/* Copyright (c) 2015, Linaro Limited > > + * All rights reserved > > + * > > + * SPDX-License-Identifier: BSD-3-Clause > > + */ > > + > > +/** > > + * @file > > + * > > + * The OpenDataPlane API to NIC drivers > > > To keep it simple, ODP API should always point towards applications. This > can be named e.g. "ODP Driver Interface" (ODP-DI ?). It's an interface to > connect drivers to ODP implementations, not an interface to develop > applications (that are NIC drivers, etc). > > All driver interface data types and calls should be also prefixed with > odpdrv_, odpd_, odpdi_ or something similar (other than odp_), so that it's > clear which definitions belong to the API and which to the driver interface. > > > > That was my original intemtion, but how would you then handle the > overlaping situation of these programming interfaces? shmem, byte order, > barriers, locks, hints ... Many API things (according to your terminology) > would also be part of the DI... Would you then alias all these > functions...? > > > > > > If driver interface needs some definitions from API side, then we include > those from the API (and maintain those in sync with API) . New / additional > definitions are prefixed with e.g. odpdi_. > > > > odpdi_ would be clearer written as odpdr_or maybe longer but clearer > odpdrv_ > > > > Driver API can consist of a bunch of odp_ defientions (re-used from API > side) and odpdi_ definitions (only for drivers). Driver interface may have > its own version numbering. An API change in those reused calls/definitions > would also bump the driver interface version. We should select carefully > which definitions and calls are really needed (or are useful) on driver > side and include only those, which means that some of the headers > (mentioned under) may need to be split into API only vs. API + DI parts. > > > > > > Pseudo code for odp/include/odp/driver/odp_driver.h > > > > This needs to be odp/include/odp_driver.h Why complicate the structure > and place the interface for the drivers down deep, lets just put all the > interfaces under odp/include it is then nice and simple with all public > interfaces found at the same level. The structure of an interfaces includes > also then mirrors each other and the includes listed below do fall out as > written. There will be very little chance of confusion by app writers. > > > > > > > > #include <api/shared_memory.h> > #include <api/std_types.h> > #include < api/byteorder.h> > > #include <api/align.h> > #include <api/sync.h> > #include <api/hints.h> > #include <api/time.h> > > > > #include <driver/dma.h> > > #include <driver/pci.h> > > #include <driver/nic.h> > > … > > > > > > -Petri > > > > > > > > > -Petri > > > > > + * > > + */ > > + > > +#ifndef ODP_DRIVER_H_ > > +#define ODP_DRIVER_H_ > > + > > +#ifdef __cplusplus > > +extern "C" { > > +#endif > > + > > +#include <odp/shared_memory.h> > > +#include <odp/std_types.h> > > +#include <odp/byteorder.h> > > +#include <odp/dma.h> > > +#include <odp/align.h> > > +#include <odp/sync.h> > > +#include <odp/hints.h> > > +#include <odp/time.h> > > + > > +#ifdef __cplusplus > > +} > > +#endif > > + > > +#endif /*ODP_DRIVER_H_*/ > > -- > > 2.1.4 > > > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > -- > > Mike Holmes > > Technical Manager - Linaro Networking Group > > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs > > > > >
diff --git a/include/odp.h b/include/odp.h index 4a93c23..1c880df 100644 --- a/include/odp.h +++ b/include/odp.h @@ -7,7 +7,7 @@ /** * @file * - * The OpenDataPlane API + * The OpenDataPlane API to applications * */ diff --git a/include/odp_driver.h b/include/odp_driver.h new file mode 100644 index 0000000..b59f7df --- /dev/null +++ b/include/odp_driver.h @@ -0,0 +1,34 @@ +/* Copyright (c) 2015, Linaro Limited + * All rights reserved + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +/** + * @file + * + * The OpenDataPlane API to NIC drivers + * + */ + +#ifndef ODP_DRIVER_H_ +#define ODP_DRIVER_H_ + +#ifdef __cplusplus +extern "C" { +#endif + +#include <odp/shared_memory.h> +#include <odp/std_types.h> +#include <odp/byteorder.h> +#include <odp/dma.h> +#include <odp/align.h> +#include <odp/sync.h> +#include <odp/hints.h> +#include <odp/time.h> + +#ifdef __cplusplus +} +#endif + +#endif /*ODP_DRIVER_H_*/
include/odp.h defines the ODP-application API (as before). include/odp_driver.h defines the new driver API. Note that the two APIs (application API and driver API) are partly overlapping: Some files such as byteorder.h, sync.h, hints.h... needs obviously to be part of both APIs. Signed-off-by: Christophe Milard <christophe.milard@linaro.org> --- include/odp.h | 2 +- include/odp_driver.h | 34 ++++++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+), 1 deletion(-) create mode 100644 include/odp_driver.h