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.o...@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.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 > >
