2016-05-18 16:09, Panu Matilainen: > On 05/18/2016 03:38 PM, Thomas Monjalon wrote: > > 2016-05-18 14:48, Panu Matilainen: > >> Calling up on the list of requirements from > >> http://dpdk.org/ml/archives/dev/2016-May/038324.html, I see a pile of > >> technical requirements but perhaps we should stop for a moment to think > >> about the use-cases first? > >> > >> To name some from the top of my head: > >> - user wants to know whether the hardware on the system is supported > > > > supported by what? > > * by a statically linked app > > * by a DPDK he has downloaded and built > > * by a DPDK provided as shared library by its Linux vendor > > All three?
Not at the same time ;) > > In the first 2 cases he knows where the files are. > > In the Linux distribution case, there can be a default directory set > > by the Linux vendor for the script looking at the infos. Only the Linux > > vendor knows where the PMDs files are. > > For case 3), EAL and the DPDK build system know where the PMDs are via > CONFIG_RTE_EAL_PMD_PATH (if set of course, otherwise there's not much hope) In case 3 (DPDK packaged in distribution), I would rely on the packager (you) who knows where the libraries are installed. You can even have a script calling system tools (lspci or other from your distribution) to get hardware infos and then check if it matches the PCI ids listed by the DPDK tool. > >> - user wants to know which package(s) need to be installed to support > >> the system hardware > > > > You mean "which DPDK packages"? > > Yes. This is of course only relevant if PMDs are split across several > different packages (splitting might not make much sense yet, but as the > number grows that might well change) > > > Are some informations showed when doing "packager search dpdk"? > > or "packager show dpdk-driverX"? > > Do you want to show the PCI ids in the description of the packages? > > Something along those lines - such things are being done by distros for > eg firmware, printer drivers, kernel drivers by modalias etc. So the packager would call the DPDK tool listing PCI ids of compiled libs. > >> - user wants to list all supported hardware before going shopping > > > > Why doing shopping? For a DPDK usage or for a specific application? > > To buy hardware which is supported by DPDK, in a general case. > > > The application should mentions the supported hardware. > > For more general DPDK information, there is this this page: > > http://dpdk.org/doc/nics > > But it may be not enough accurate for some PCI id exceptions. > > For more details, he must use a listing tool. > > Yes. The point is, what kind of tool/solution can be made to behave > identically between shared and static configs, in a user-friendly way. I > just listed a few obvious (to me at least) use-cases, and was asking for > others that I didn't think of. For a user-friendly output, we should not export only PCI ids but also the commercial names. About the static/shared case, we can have a script which look at testpmd plus the shared libs. In a dev space, it is easy to find the files. In a packaged system, the script can get some configuration variables from the distribution.
