| Message ID | 1478517324-11324-4-git-send-email-christophe.milard@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 11/07/16 14:15, Christophe Milard wrote: > Function added on the north API to load drivers. > > Signed-off-by: Christophe Milard <christophe.milard@linaro.org> > --- > include/odp/api/spec/init.h | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/include/odp/api/spec/init.h b/include/odp/api/spec/init.h > index 154cdf8..bfe43df 100644 > --- a/include/odp/api/spec/init.h > +++ b/include/odp/api/spec/init.h > @@ -270,6 +270,22 @@ int odp_init_local(odp_instance_t instance, odp_thread_type_t thr_type); > int odp_term_local(void); > > /** > + * Driver loading > + * > + * This function is used by the application to load NIC drivers into ODP. s/NIC divers/ODP drivers/ > + * Calls to this function are optional, but should be performed (if any) > + * after odp_init_global > + * > + * > + * @param filename Driver shared lib (dynamic library) it it full file name or just name of the library? > + * > + * @retval 0 on success > + * @retval <0 on failure > + * > + */ > +int odp_load_driver(const char *filename); odp_driver_load() or even odp_drv_load(). I think it's better to keep common prefix for drivers. Maxim. > + > +/** > * @} > */ >
On 8 November 2016 at 14:56, Maxim Uvarov <maxim.uvarov@linaro.org> wrote: > On 11/07/16 14:15, Christophe Milard wrote: >> >> Function added on the north API to load drivers. >> >> Signed-off-by: Christophe Milard <christophe.milard@linaro.org> >> --- >> include/odp/api/spec/init.h | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> >> diff --git a/include/odp/api/spec/init.h b/include/odp/api/spec/init.h >> index 154cdf8..bfe43df 100644 >> --- a/include/odp/api/spec/init.h >> +++ b/include/odp/api/spec/init.h >> @@ -270,6 +270,22 @@ int odp_init_local(odp_instance_t instance, >> odp_thread_type_t thr_type); >> int odp_term_local(void); >> /** >> + * Driver loading >> + * >> + * This function is used by the application to load NIC drivers into ODP. > > > s/NIC divers/ODP drivers/ Sorry: don't understand this comment. what do you mean? > >> + * Calls to this function are optional, but should be performed (if any) >> + * after odp_init_global >> + * >> + * >> + * @param filename Driver shared lib (dynamic library) > > > it it full file name or just name of the library? Whatever dl_open supports (full path or filename searched in LD_BIBRARY...) Will include that in the comment =>V3 > > >> + * >> + * @retval 0 on success >> + * @retval <0 on failure >> + * >> + */ >> +int odp_load_driver(const char *filename); > > > odp_driver_load() or even odp_drv_load(). > > I think it's better to keep common prefix for drivers. then it should be odp_driver_load, because the prefix in odp only as this function is part of the application API => V3 Christophe > Maxim. > > >> + >> +/** >> * @} >> */ >> > >
On 11/08/16 17:09, Christophe Milard wrote: > On 8 November 2016 at 14:56, Maxim Uvarov <maxim.uvarov@linaro.org> wrote: >> On 11/07/16 14:15, Christophe Milard wrote: >>> Function added on the north API to load drivers. >>> >>> Signed-off-by: Christophe Milard <christophe.milard@linaro.org> >>> --- >>> include/odp/api/spec/init.h | 16 ++++++++++++++++ >>> 1 file changed, 16 insertions(+) >>> >>> diff --git a/include/odp/api/spec/init.h b/include/odp/api/spec/init.h >>> index 154cdf8..bfe43df 100644 >>> --- a/include/odp/api/spec/init.h >>> +++ b/include/odp/api/spec/init.h >>> @@ -270,6 +270,22 @@ int odp_init_local(odp_instance_t instance, >>> odp_thread_type_t thr_type); >>> int odp_term_local(void); >>> /** >>> + * Driver loading >>> + * >>> + * This function is used by the application to load NIC drivers into ODP. >> >> s/NIC divers/ODP drivers/ > Sorry: don't understand this comment. what do you mean? change text from 'NIC drivers' to 'ODP dirvers' due to driver might be not only for NIC. >>> + * Calls to this function are optional, but should be performed (if any) >>> + * after odp_init_global >>> + * >>> + * >>> + * @param filename Driver shared lib (dynamic library) >> >> it it full file name or just name of the library? > Whatever dl_open supports (full path or filename searched in LD_BIBRARY...) > Will include that in the comment =>V3 yes comment needs to be updated. Argument might be also "*name" or "*libname" >> >>> + * >>> + * @retval 0 on success >>> + * @retval <0 on failure >>> + * >>> + */ >>> +int odp_load_driver(const char *filename); >> >> odp_driver_load() or even odp_drv_load(). >> >> I think it's better to keep common prefix for drivers. > then it should be odp_driver_load, because the prefix in odp only as > this function is part of the application API > => V3 ok. > Christophe > >> Maxim. >> >> >>> + >>> +/** >>> * @} >>> */ >>> >>
> /** > + * Driver loading > + * > + * This function is used by the application to load NIC drivers into ODP. > + * Calls to this function are optional, but should be performed (if any) > + * after odp_init_global > + * > + * > + * @param filename Driver shared lib (dynamic library) > + * > + * @retval 0 on success > + * @retval <0 on failure > + * > + */ > +int odp_load_driver(const char *filename); Why application should explicitly need to load a driver ? Why it cannot happen as part of odp_pktio_open() ? To me a better approach would be: * user reads implementation documentation or uses system commands to find a list of available interfaces * odp_global_init() finds out available pktio interfaces and drivers for those * application opens the interface the user commands (just like today) * pktio_open call loads the driver Or with more ODP support: * odp_global_init() finds out available pktio interfaces and drivers for those * a new API call lists all available interfaces * application chooses an interface from the list and calls open * pktio_open call loads the driver -Petri
On 16 November 2016 at 10:07, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com> wrote: > >> /** >> + * Driver loading >> + * >> + * This function is used by the application to load NIC drivers into ODP. >> + * Calls to this function are optional, but should be performed (if any) >> + * after odp_init_global >> + * >> + * >> + * @param filename Driver shared lib (dynamic library) >> + * >> + * @retval 0 on success >> + * @retval <0 on failure >> + * >> + */ >> +int odp_load_driver(const char *filename); > > Why application should explicitly need to load a driver ? Why it cannot happen as part of odp_pktio_open() ? > > To me a better approach would be: > * user reads implementation documentation or uses system commands to find a list of available interfaces > * odp_global_init() finds out available pktio interfaces and drivers for those > * application opens the interface the user commands (just like today) > * pktio_open call loads the driver > > Or with more ODP support: > * odp_global_init() finds out available pktio interfaces and drivers for those > * a new API call lists all available interfaces > * application chooses an interface from the list and calls open > * pktio_open call loads the driver > > > -Petri Having ODP finding the driver by itself means "hard-coding" the list of available drivers (in the sense that ODP must know in advance what drivers matches what interface and where to find these drivers). The approach above let people do their own driver and attach it to ODP whithout any pre-requirements on ODP. When we have a set of "drivers we like", nothing prevent us from loading a default set of drivers at init. Unless the driver name (and path) is given as part as the pktio device name, which would just be awfull, we need such a load function to enable private driver loading. Moreover, the driver must be loaded to be probed: The drivers must tell what they can do, not ODP. I think the application should as a little aware as possible of drivers (and what HW they match) but should be given a way to load private drivers. The approach here enable that. Load your own driver (or none if it is in the default set), then open pktios without specifying any driver (note that 1 driver may be handling many interfaces) I think having an API call to list available interfaces makes sense, and does stress my proposal: Drivers must be loaded and probed to build that list. Christophe.
Hello, If the north API is the one visible by ODP applications then I don't think it is a good idea to expose that. DPDK exposed it at the beginning and is now internal. That said there must be a standard way to manage drivers fir the benefit of the device framework. I don't think the idea of integrating it with packetio open because packetio is not really a device. It is an abstract way of dealing with ports which may be hosted on a device (NIC) or on the platform (SoC). It can be done as a PoC (that's what I do with virtio-net exploratiry project) but that is not a long term solution. FF Le mercredi 16 novembre 2016, Christophe Milard < christophe.milard@linaro.org> a écrit : > On 16 November 2016 at 10:07, Savolainen, Petri (Nokia - FI/Espoo) > <petri.savolainen@nokia-bell-labs.com <javascript:;>> wrote: > > > >> /** > >> + * Driver loading > >> + * > >> + * This function is used by the application to load NIC drivers into > ODP. > >> + * Calls to this function are optional, but should be performed (if > any) > >> + * after odp_init_global > >> + * > >> + * > >> + * @param filename Driver shared lib (dynamic library) > >> + * > >> + * @retval 0 on success > >> + * @retval <0 on failure > >> + * > >> + */ > >> +int odp_load_driver(const char *filename); > > > > Why application should explicitly need to load a driver ? Why it cannot > happen as part of odp_pktio_open() ? > > > > To me a better approach would be: > > * user reads implementation documentation or uses system commands to > find a list of available interfaces > > * odp_global_init() finds out available pktio interfaces and drivers for > those > > * application opens the interface the user commands (just like today) > > * pktio_open call loads the driver > > > > Or with more ODP support: > > * odp_global_init() finds out available pktio interfaces and drivers for > those > > * a new API call lists all available interfaces > > * application chooses an interface from the list and calls open > > * pktio_open call loads the driver > > > > > > -Petri > > > Having ODP finding the driver by itself means "hard-coding" the list > of available drivers (in the sense that ODP must know in advance what > drivers matches what interface and where to find these drivers). > > The approach above let people do their own driver and attach it to ODP > whithout any pre-requirements on ODP. > When we have a set of "drivers we like", nothing prevent us from > loading a default set of drivers at init. > Unless the driver name (and path) is given as part as the pktio device > name, which would just be awfull, we need such a load function to > enable private driver loading. > > Moreover, the driver must be loaded to be probed: The drivers must > tell what they can do, not ODP. > > I think the application should as a little aware as possible of > drivers (and what HW they match) but should be given a way to load > private drivers. The approach here enable that. Load your own driver > (or none if it is in the default set), then open pktios without > specifying any driver (note that 1 driver may be handling many > interfaces) > > I think having an API call to list available interfaces makes sense, > and does stress my proposal: Drivers must be loaded and probed to > build that list. > > Christophe. > -- [image: Linaro] <http://www.linaro.org/> François-Frédéric Ozog | *Director Linaro Networking Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
So what? If we don't allow to load a driver from the north interface, where should they be loaded from?? Or are we saying that we go for a predefined list of driver only? So drivers have to be .so files (because of autotools), but we don't give the possibility to load a free driver?? Christophe On 16 November 2016 at 11:45, Francois Ozog <francois.ozog@linaro.org> wrote: > Hello, > > If the north API is the one visible by ODP applications then I don't think > it is a good idea to expose that. > DPDK exposed it at the beginning and is now internal. > > That said there must be a standard way to manage drivers fir the benefit > of the device framework. > > I don't think the idea of integrating it with packetio open because > packetio is not really a device. It is an abstract way of dealing with > ports which may be hosted on a device (NIC) or on the platform (SoC). > It can be done as a PoC (that's what I do with virtio-net exploratiry > project) but that is not a long term solution. > > FF > > > Le mercredi 16 novembre 2016, Christophe Milard < > christophe.milard@linaro.org> a écrit : > >> On 16 November 2016 at 10:07, Savolainen, Petri (Nokia - FI/Espoo) >> <petri.savolainen@nokia-bell-labs.com> wrote: >> > >> >> /** >> >> + * Driver loading >> >> + * >> >> + * This function is used by the application to load NIC drivers into >> ODP. >> >> + * Calls to this function are optional, but should be performed (if >> any) >> >> + * after odp_init_global >> >> + * >> >> + * >> >> + * @param filename Driver shared lib (dynamic library) >> >> + * >> >> + * @retval 0 on success >> >> + * @retval <0 on failure >> >> + * >> >> + */ >> >> +int odp_load_driver(const char *filename); >> > >> > Why application should explicitly need to load a driver ? Why it cannot >> happen as part of odp_pktio_open() ? >> > >> > To me a better approach would be: >> > * user reads implementation documentation or uses system commands to >> find a list of available interfaces >> > * odp_global_init() finds out available pktio interfaces and drivers >> for those >> > * application opens the interface the user commands (just like today) >> > * pktio_open call loads the driver >> > >> > Or with more ODP support: >> > * odp_global_init() finds out available pktio interfaces and drivers >> for those >> > * a new API call lists all available interfaces >> > * application chooses an interface from the list and calls open >> > * pktio_open call loads the driver >> > >> > >> > -Petri >> >> >> Having ODP finding the driver by itself means "hard-coding" the list >> of available drivers (in the sense that ODP must know in advance what >> drivers matches what interface and where to find these drivers). >> >> The approach above let people do their own driver and attach it to ODP >> whithout any pre-requirements on ODP. >> When we have a set of "drivers we like", nothing prevent us from >> loading a default set of drivers at init. >> Unless the driver name (and path) is given as part as the pktio device >> name, which would just be awfull, we need such a load function to >> enable private driver loading. >> >> Moreover, the driver must be loaded to be probed: The drivers must >> tell what they can do, not ODP. >> >> I think the application should as a little aware as possible of >> drivers (and what HW they match) but should be given a way to load >> private drivers. The approach here enable that. Load your own driver >> (or none if it is in the default set), then open pktios without >> specifying any driver (note that 1 driver may be handling many >> interfaces) >> >> I think having an API call to list available interfaces makes sense, >> and does stress my proposal: Drivers must be loaded and probed to >> build that list. >> >> Christophe. >> > > > -- > [image: Linaro] <http://www.linaro.org/> > François-Frédéric Ozog | *Director Linaro Networking Group* > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog > > >
Why not just scanning a directory or give a command line parameter? On 16 November 2016 at 12:05, Christophe Milard < christophe.milard@linaro.org> wrote: > So what? > If we don't allow to load a driver from the north interface, where should > they be loaded from?? > Or are we saying that we go for a predefined list of driver only? > > So drivers have to be .so files (because of autotools), but we don't give > the possibility to load a free driver?? > > Christophe > > On 16 November 2016 at 11:45, Francois Ozog <francois.ozog@linaro.org> > wrote: > >> Hello, >> >> If the north API is the one visible by ODP applications then I don't >> think it is a good idea to expose that. >> DPDK exposed it at the beginning and is now internal. >> >> That said there must be a standard way to manage drivers fir the benefit >> of the device framework. >> >> I don't think the idea of integrating it with packetio open because >> packetio is not really a device. It is an abstract way of dealing with >> ports which may be hosted on a device (NIC) or on the platform (SoC). >> It can be done as a PoC (that's what I do with virtio-net exploratiry >> project) but that is not a long term solution. >> >> FF >> >> >> Le mercredi 16 novembre 2016, Christophe Milard < >> christophe.milard@linaro.org> a écrit : >> >>> On 16 November 2016 at 10:07, Savolainen, Petri (Nokia - FI/Espoo) >>> <petri.savolainen@nokia-bell-labs.com> wrote: >>> > >>> >> /** >>> >> + * Driver loading >>> >> + * >>> >> + * This function is used by the application to load NIC drivers into >>> ODP. >>> >> + * Calls to this function are optional, but should be performed (if >>> any) >>> >> + * after odp_init_global >>> >> + * >>> >> + * >>> >> + * @param filename Driver shared lib (dynamic library) >>> >> + * >>> >> + * @retval 0 on success >>> >> + * @retval <0 on failure >>> >> + * >>> >> + */ >>> >> +int odp_load_driver(const char *filename); >>> > >>> > Why application should explicitly need to load a driver ? Why it >>> cannot happen as part of odp_pktio_open() ? >>> > >>> > To me a better approach would be: >>> > * user reads implementation documentation or uses system commands to >>> find a list of available interfaces >>> > * odp_global_init() finds out available pktio interfaces and drivers >>> for those >>> > * application opens the interface the user commands (just like today) >>> > * pktio_open call loads the driver >>> > >>> > Or with more ODP support: >>> > * odp_global_init() finds out available pktio interfaces and drivers >>> for those >>> > * a new API call lists all available interfaces >>> > * application chooses an interface from the list and calls open >>> > * pktio_open call loads the driver >>> > >>> > >>> > -Petri >>> >>> >>> Having ODP finding the driver by itself means "hard-coding" the list >>> of available drivers (in the sense that ODP must know in advance what >>> drivers matches what interface and where to find these drivers). >>> >>> The approach above let people do their own driver and attach it to ODP >>> whithout any pre-requirements on ODP. >>> When we have a set of "drivers we like", nothing prevent us from >>> loading a default set of drivers at init. >>> Unless the driver name (and path) is given as part as the pktio device >>> name, which would just be awfull, we need such a load function to >>> enable private driver loading. >>> >>> Moreover, the driver must be loaded to be probed: The drivers must >>> tell what they can do, not ODP. >>> >>> I think the application should as a little aware as possible of >>> drivers (and what HW they match) but should be given a way to load >>> private drivers. The approach here enable that. Load your own driver >>> (or none if it is in the default set), then open pktios without >>> specifying any driver (note that 1 driver may be handling many >>> interfaces) >>> >>> I think having an API call to list available interfaces makes sense, >>> and does stress my proposal: Drivers must be loaded and probed to >>> build that list. >>> >>> Christophe. >>> >> >> >> -- >> [image: Linaro] <http://www.linaro.org/> >> François-Frédéric Ozog | *Director Linaro Networking Group* >> T: +33.67221.6485 >> francois.ozog@linaro.org | Skype: ffozog >> >> >> > -- [image: Linaro] <http://www.linaro.org/> François-Frédéric Ozog | *Director Linaro Networking Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
Command line parameters will go to the application. As far as I know, we have no ODP parameters at this time, and they would require some command line processing cooperation with the application (main(argv, argc)) is in the app, we are just a lib). That put apps using getopts in a bad position. argparse is really the command line parser which thought about subparsing, but is not always used. Command line parameters also assume a command :-). If ODP comes with a shell-less system this becomes less obvious. I agree that in some cases (command line from linux) it would be clearer, but... Scanning a directory makes assumption on the directory structure, unless we can specify that directory from the north interface (and then, aren't we back more or less to the initial proposal?), or command line. I have hard to see the problem with enabling driver loading from the north interface: The apps which needs a specific driver (because they run on a specific HW) have a chance to load what they need. I agree a set of default driver would make sense, and possibly command line args if they come into picture. But dynamic loading make sense to me: both command line args and directory scan implies init-only driver loading, right? (of course on linux one could receive an event on directory write...) In dpdk, many drivers come with dpdk. Possibly we could do that too, and that could reduce the usage on the driver_load function... Christophe On 16 November 2016 at 12:20, Francois Ozog <francois.ozog@linaro.org> wrote: > Why not just scanning a directory or give a command line parameter? > > On 16 November 2016 at 12:05, Christophe Milard < > christophe.milard@linaro.org> wrote: > >> So what? >> If we don't allow to load a driver from the north interface, where should >> they be loaded from?? >> Or are we saying that we go for a predefined list of driver only? >> >> So drivers have to be .so files (because of autotools), but we don't give >> the possibility to load a free driver?? >> >> Christophe >> >> On 16 November 2016 at 11:45, Francois Ozog <francois.ozog@linaro.org> >> wrote: >> >>> Hello, >>> >>> If the north API is the one visible by ODP applications then I don't >>> think it is a good idea to expose that. >>> DPDK exposed it at the beginning and is now internal. >>> >>> That said there must be a standard way to manage drivers fir the benefit >>> of the device framework. >>> >>> I don't think the idea of integrating it with packetio open because >>> packetio is not really a device. It is an abstract way of dealing with >>> ports which may be hosted on a device (NIC) or on the platform (SoC). >>> It can be done as a PoC (that's what I do with virtio-net exploratiry >>> project) but that is not a long term solution. >>> >>> FF >>> >>> >>> Le mercredi 16 novembre 2016, Christophe Milard < >>> christophe.milard@linaro.org> a écrit : >>> >>>> On 16 November 2016 at 10:07, Savolainen, Petri (Nokia - FI/Espoo) >>>> <petri.savolainen@nokia-bell-labs.com> wrote: >>>> > >>>> >> /** >>>> >> + * Driver loading >>>> >> + * >>>> >> + * This function is used by the application to load NIC drivers >>>> into ODP. >>>> >> + * Calls to this function are optional, but should be performed (if >>>> any) >>>> >> + * after odp_init_global >>>> >> + * >>>> >> + * >>>> >> + * @param filename Driver shared lib (dynamic library) >>>> >> + * >>>> >> + * @retval 0 on success >>>> >> + * @retval <0 on failure >>>> >> + * >>>> >> + */ >>>> >> +int odp_load_driver(const char *filename); >>>> > >>>> > Why application should explicitly need to load a driver ? Why it >>>> cannot happen as part of odp_pktio_open() ? >>>> > >>>> > To me a better approach would be: >>>> > * user reads implementation documentation or uses system commands to >>>> find a list of available interfaces >>>> > * odp_global_init() finds out available pktio interfaces and drivers >>>> for those >>>> > * application opens the interface the user commands (just like today) >>>> > * pktio_open call loads the driver >>>> > >>>> > Or with more ODP support: >>>> > * odp_global_init() finds out available pktio interfaces and drivers >>>> for those >>>> > * a new API call lists all available interfaces >>>> > * application chooses an interface from the list and calls open >>>> > * pktio_open call loads the driver >>>> > >>>> > >>>> > -Petri >>>> >>>> >>>> Having ODP finding the driver by itself means "hard-coding" the list >>>> of available drivers (in the sense that ODP must know in advance what >>>> drivers matches what interface and where to find these drivers). >>>> >>>> The approach above let people do their own driver and attach it to ODP >>>> whithout any pre-requirements on ODP. >>>> When we have a set of "drivers we like", nothing prevent us from >>>> loading a default set of drivers at init. >>>> Unless the driver name (and path) is given as part as the pktio device >>>> name, which would just be awfull, we need such a load function to >>>> enable private driver loading. >>>> >>>> Moreover, the driver must be loaded to be probed: The drivers must >>>> tell what they can do, not ODP. >>>> >>>> I think the application should as a little aware as possible of >>>> drivers (and what HW they match) but should be given a way to load >>>> private drivers. The approach here enable that. Load your own driver >>>> (or none if it is in the default set), then open pktios without >>>> specifying any driver (note that 1 driver may be handling many >>>> interfaces) >>>> >>>> I think having an API call to list available interfaces makes sense, >>>> and does stress my proposal: Drivers must be loaded and probed to >>>> build that list. >>>> >>>> Christophe. >>>> >>> >>> >>> -- >>> [image: Linaro] <http://www.linaro.org/> >>> François-Frédéric Ozog | *Director Linaro Networking Group* >>> T: +33.67221.6485 >>> francois.ozog@linaro.org | Skype: ffozog >>> >>> >>> >> > > > -- > [image: Linaro] <http://www.linaro.org/> > François-Frédéric Ozog | *Director Linaro Networking Group* > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog > >
ODP is about abstracting things so that applications can concentrate on the logic. Exposing drivers on this northbound interface contradicts the essence of ODP. ODP implementers will decide how they will accomodate driver "additions". One may even decide to retrieve drivers through TFTP ;-) If we say there are: - a device framework - a driver framework You can expose driver loading interface as part of the driver framework so that implementers have a standard way to "activate" drivers that they have retrieved the way they think appropriate. The device framework will leverage the driver framework to associate devices and drivers. FF PS: dpdk-app <EAL command line parameters> -- <application parameters> On 16 November 2016 at 12:49, Christophe Milard < christophe.milard@linaro.org> wrote: > Command line parameters will go to the application. As far as I know, we > have no ODP parameters at this time, and they would require some command > line processing cooperation with the application (main(argv, argc)) is in > the app, we are just a lib). That put apps using getopts in a bad position. > argparse is really the command line parser which thought about subparsing, > but is not always used. > Command line parameters also assume a command :-). If ODP comes with a > shell-less system this becomes less obvious. > I agree that in some cases (command line from linux) it would be clearer, > but... > > Scanning a directory makes assumption on the directory structure, unless > we can specify that directory from the north interface (and then, aren't we > back more or less to the initial proposal?), or command line. > > I have hard to see the problem with enabling driver loading from the north > interface: The apps which needs a specific driver (because they run on a > specific HW) have a chance to load what they need. > I agree a set of default driver would make sense, and possibly command > line args if they come into picture. But dynamic loading make sense to me: > both command line args and directory scan implies init-only driver loading, > right? (of course on linux one could receive an event on directory write...) > > In dpdk, many drivers come with dpdk. Possibly we could do that too, and > that could reduce the usage on the driver_load function... > > Christophe > > > > On 16 November 2016 at 12:20, Francois Ozog <francois.ozog@linaro.org> > wrote: > >> Why not just scanning a directory or give a command line parameter? >> >> On 16 November 2016 at 12:05, Christophe Milard < >> christophe.milard@linaro.org> wrote: >> >>> So what? >>> If we don't allow to load a driver from the north interface, where >>> should they be loaded from?? >>> Or are we saying that we go for a predefined list of driver only? >>> >>> So drivers have to be .so files (because of autotools), but we don't >>> give the possibility to load a free driver?? >>> >>> Christophe >>> >>> On 16 November 2016 at 11:45, Francois Ozog <francois.ozog@linaro.org> >>> wrote: >>> >>>> Hello, >>>> >>>> If the north API is the one visible by ODP applications then I don't >>>> think it is a good idea to expose that. >>>> DPDK exposed it at the beginning and is now internal. >>>> >>>> That said there must be a standard way to manage drivers fir the >>>> benefit of the device framework. >>>> >>>> I don't think the idea of integrating it with packetio open because >>>> packetio is not really a device. It is an abstract way of dealing with >>>> ports which may be hosted on a device (NIC) or on the platform (SoC). >>>> It can be done as a PoC (that's what I do with virtio-net exploratiry >>>> project) but that is not a long term solution. >>>> >>>> FF >>>> >>>> >>>> Le mercredi 16 novembre 2016, Christophe Milard < >>>> christophe.milard@linaro.org> a écrit : >>>> >>>>> On 16 November 2016 at 10:07, Savolainen, Petri (Nokia - FI/Espoo) >>>>> <petri.savolainen@nokia-bell-labs.com> wrote: >>>>> > >>>>> >> /** >>>>> >> + * Driver loading >>>>> >> + * >>>>> >> + * This function is used by the application to load NIC drivers >>>>> into ODP. >>>>> >> + * Calls to this function are optional, but should be performed >>>>> (if any) >>>>> >> + * after odp_init_global >>>>> >> + * >>>>> >> + * >>>>> >> + * @param filename Driver shared lib (dynamic library) >>>>> >> + * >>>>> >> + * @retval 0 on success >>>>> >> + * @retval <0 on failure >>>>> >> + * >>>>> >> + */ >>>>> >> +int odp_load_driver(const char *filename); >>>>> > >>>>> > Why application should explicitly need to load a driver ? Why it >>>>> cannot happen as part of odp_pktio_open() ? >>>>> > >>>>> > To me a better approach would be: >>>>> > * user reads implementation documentation or uses system commands to >>>>> find a list of available interfaces >>>>> > * odp_global_init() finds out available pktio interfaces and drivers >>>>> for those >>>>> > * application opens the interface the user commands (just like today) >>>>> > * pktio_open call loads the driver >>>>> > >>>>> > Or with more ODP support: >>>>> > * odp_global_init() finds out available pktio interfaces and drivers >>>>> for those >>>>> > * a new API call lists all available interfaces >>>>> > * application chooses an interface from the list and calls open >>>>> > * pktio_open call loads the driver >>>>> > >>>>> > >>>>> > -Petri >>>>> >>>>> >>>>> Having ODP finding the driver by itself means "hard-coding" the list >>>>> of available drivers (in the sense that ODP must know in advance what >>>>> drivers matches what interface and where to find these drivers). >>>>> >>>>> The approach above let people do their own driver and attach it to ODP >>>>> whithout any pre-requirements on ODP. >>>>> When we have a set of "drivers we like", nothing prevent us from >>>>> loading a default set of drivers at init. >>>>> Unless the driver name (and path) is given as part as the pktio device >>>>> name, which would just be awfull, we need such a load function to >>>>> enable private driver loading. >>>>> >>>>> Moreover, the driver must be loaded to be probed: The drivers must >>>>> tell what they can do, not ODP. >>>>> >>>>> I think the application should as a little aware as possible of >>>>> drivers (and what HW they match) but should be given a way to load >>>>> private drivers. The approach here enable that. Load your own driver >>>>> (or none if it is in the default set), then open pktios without >>>>> specifying any driver (note that 1 driver may be handling many >>>>> interfaces) >>>>> >>>>> I think having an API call to list available interfaces makes sense, >>>>> and does stress my proposal: Drivers must be loaded and probed to >>>>> build that list. >>>>> >>>>> Christophe. >>>>> >>>> >>>> >>>> -- >>>> [image: Linaro] <http://www.linaro.org/> >>>> François-Frédéric Ozog | *Director Linaro Networking Group* >>>> T: +33.67221.6485 >>>> francois.ozog@linaro.org | Skype: ffozog >>>> >>>> >>>> >>> >> >> >> -- >> [image: Linaro] <http://www.linaro.org/> >> François-Frédéric Ozog | *Director Linaro Networking Group* >> T: +33.67221.6485 >> francois.ozog@linaro.org | Skype: ffozog >> >> > -- [image: Linaro] <http://www.linaro.org/> François-Frédéric Ozog | *Director Linaro Networking Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
Something like this would not need application to load any drivers, just open pktio with correct name
1) Place all driver libs into a well know directory e.g. odp/drv/libs (user can which drivers to install into this dir)
2) Only drivers in the directory are considered available
3) Names and drivers are assigned to interfaces, if not done already by the system. Today this is done outside of ODP, with driver interface it could be done also during global_init()
4) odp_global_init() finds out which libs (== drivers) are in the dir and may be uses also config file (which driver is preferred for an interface)
5) The drv interface includes function calls for odp to request additional information about a driver: which NICs are supported, which drivers are already connected to which interface, ..., etc. Anyway, after this point ODP knows mapping between name ("eth0") -> interface (PCIe slot 5, 10GE port #2) -> driver ("odpdrv_niantic.so")
6) Application opens pktios with the interface names it got from the user ("eth0"). Driver may be "loaded" as part of pktio_open() if not done already, at least the drv interface functions are bound to the correct lib.
-Petri
From: Christophe Milard [mailto:christophe.milard@linaro.org]
Sent: Wednesday, November 16, 2016 1:49 PM
To: Francois Ozog <francois.ozog@linaro.org>
Cc: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com>; yi.he@linaro.org; mike.holmes@linaro.org; bill.fischofer@linaro.org; lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [API-NEXT PATCHv2 3/5] api: init: driver load function added
Command line parameters will go to the application. As far as I know, we have no ODP parameters at this time, and they would require some command line processing cooperation with the application (main(argv, argc)) is in the app, we are just a lib). That put apps using getopts in a bad position. argparse is really the command line parser which thought about subparsing, but is not always used.
Command line parameters also assume a command :-). If ODP comes with a shell-less system this becomes less obvious.
I agree that in some cases (command line from linux) it would be clearer, but...
Scanning a directory makes assumption on the directory structure, unless we can specify that directory from the north interface (and then, aren't we back more or less to the initial proposal?), or command line.
I have hard to see the problem with enabling driver loading from the north interface: The apps which needs a specific driver (because they run on a specific HW) have a chance to load what they need.
I agree a set of default driver would make sense, and possibly command line args if they come into picture. But dynamic loading make sense to me: both command line args and directory scan implies init-only driver loading, right? (of course on linux one could receive an event on directory write...)
In dpdk, many drivers come with dpdk. Possibly we could do that too, and that could reduce the usage on the driver_load function...
Christophe
On 16 November 2016 at 12:20, Francois Ozog <francois.ozog@linaro.org> wrote:
Why not just scanning a directory or give a command line parameter?
On 16 November 2016 at 12:05, Christophe Milard <christophe.milard@linaro.org> wrote:
So what?
If we don't allow to load a driver from the north interface, where should they be loaded from??
Or are we saying that we go for a predefined list of driver only?
So drivers have to be .so files (because of autotools), but we don't give the possibility to load a free driver??
Christophe
On 16 November 2016 at 11:45, Francois Ozog <francois.ozog@linaro.org> wrote:
Hello,
If the north API is the one visible by ODP applications then I don't think it is a good idea to expose that.
DPDK exposed it at the beginning and is now internal.
That said there must be a standard way to manage drivers fir the benefit of the device framework.
I don't think the idea of integrating it with packetio open because packetio is not really a device. It is an abstract way of dealing with ports which may be hosted on a device (NIC) or on the platform (SoC).
It can be done as a PoC (that's what I do with virtio-net exploratiry project) but that is not a long term solution.
FF
Le mercredi 16 novembre 2016, Christophe Milard <christophe.milard@linaro.org> a écrit :
On 16 November 2016 at 10:07, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolainen@nokia-bell-labs.com> wrote:
>
>> /**
>> + * Driver loading
>> + *
>> + * This function is used by the application to load NIC drivers into ODP.
>> + * Calls to this function are optional, but should be performed (if any)
>> + * after odp_init_global
>> + *
>> + *
>> + * @param filename Driver shared lib (dynamic library)
>> + *
>> + * @retval 0 on success
>> + * @retval <0 on failure
>> + *
>> + */
>> +int odp_load_driver(const char *filename);
>
> Why application should explicitly need to load a driver ? Why it cannot happen as part of odp_pktio_open() ?
>
> To me a better approach would be:
> * user reads implementation documentation or uses system commands to find a list of available interfaces
> * odp_global_init() finds out available pktio interfaces and drivers for those
> * application opens the interface the user commands (just like today)
> * pktio_open call loads the driver
>
> Or with more ODP support:
> * odp_global_init() finds out available pktio interfaces and drivers for those
> * a new API call lists all available interfaces
> * application chooses an interface from the list and calls open
> * pktio_open call loads the driver
>
>
> -Petri
Having ODP finding the driver by itself means "hard-coding" the list
of available drivers (in the sense that ODP must know in advance what
drivers matches what interface and where to find these drivers).
The approach above let people do their own driver and attach it to ODP
whithout any pre-requirements on ODP.
When we have a set of "drivers we like", nothing prevent us from
loading a default set of drivers at init.
Unless the driver name (and path) is given as part as the pktio device
name, which would just be awfull, we need such a load function to
enable private driver loading.
Moreover, the driver must be loaded to be probed: The drivers must
tell what they can do, not ODP.
I think the application should as a little aware as possible of
drivers (and what HW they match) but should be given a way to load
private drivers. The approach here enable that. Load your own driver
(or none if it is in the default set), then open pktios without
specifying any driver (note that 1 driver may be handling many
interfaces)
I think having an API call to list available interfaces makes sense,
and does stress my proposal: Drivers must be loaded and probed to
build that list.
Christophe.
--
François-Frédéric Ozog | Director Linaro Networking Group
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
--
François-Frédéric Ozog | Director Linaro Networking Group
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
diff --git a/include/odp/api/spec/init.h b/include/odp/api/spec/init.h index 154cdf8..bfe43df 100644 --- a/include/odp/api/spec/init.h +++ b/include/odp/api/spec/init.h @@ -270,6 +270,22 @@ int odp_init_local(odp_instance_t instance, odp_thread_type_t thr_type); int odp_term_local(void); /** + * Driver loading + * + * This function is used by the application to load NIC drivers into ODP. + * Calls to this function are optional, but should be performed (if any) + * after odp_init_global + * + * + * @param filename Driver shared lib (dynamic library) + * + * @retval 0 on success + * @retval <0 on failure + * + */ +int odp_load_driver(const char *filename); + +/** * @} */
Function added on the north API to load drivers. Signed-off-by: Christophe Milard <christophe.milard@linaro.org> --- include/odp/api/spec/init.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) -- 2.7.4