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.o...@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.mil...@linaro.org> a écrit : > >> On 16 November 2016 at 10:07, Savolainen, Petri (Nokia - FI/Espoo) >> <petri.savolai...@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.o...@linaro.org | Skype: ffozog > > >
