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 <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.o...@linaro.org | Skype: ffozog
