Why not just scanning a directory or give a command line parameter? On 16 November 2016 at 12:05, Christophe Milard < christophe.mil...@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.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 >> >> >> > -- [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
