2016-09-01 10:41, Stephen Hemminger:

Neil Horman [off-list ref] wrote:

quoted

On Thu, Sep 01, 2016 at 12:55:27PM +0000, Trahe, Fiona wrote:

quoted

From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz

quoted

On 08/31/2016 03:27 PM, Neil Horman wrote:  

quoted

Oh, I see, so your list is a colon delimited list of module load sets, where at
least one set must succeed by loading all modules in its set, but the failure of
any one set isn't fatal to the process?  e.g. a string like this:

uio,igb_uio:vfio,vfio-pci

could be interpreted to mean "I must load (uio AND igb_uio) OR (vfio AND
vfio-pci).  If the evaluation of that statement results in false, then the
operation fails, otherwise it succedes.

If thats the case, then, apologies, we're on the same page, and this will work
just fine.  

Yep, that's the idea.

Colon and commas are the best separators I've thought about, but any
idea to make the syntax clearer is welcome ;)

Maybe a syntax like is clearer:
  "(mod1 & mod2)|(mod3 & mod4)" ?
But it would let the user think that more complex expressions are valid,
like "(mod1 & (mod2 | mod3)) | mod4", which is probably overkill.

This RFC seems like a good idea - and something the Intel QuickAssist PMD could benefit from.
However the (mod1 & mod2) can handle the QAT case better in my opinion.
i.e.
as well as needing one of 
* uio igb_uio
* uio uio_pci_generic
* vfio vfio-pci
QAT PMD also needs one of (depending on which physical device is plugged)
 * qat_dh895xcc
 * qat_c62x
 * qat_c3xxx

So the original syntax would result in a very long list of possible variations.
What really reflects the dependencies would be 
((uio & igb_uio) | (uio & uio_pci_generic) | (vfio & vfio_pci)) & (qat_dh895xcc | qat_c62x | qat_c3xxx)
  

Ah, I didn't consider that hardware specifics might create a use case where a
pmd must have one or more kernel modules available for hw support.  Perhaps it
is worthwhile to automate hardware support - that is to say, any module loading
script should automatically look at the pci table exported from a pmd, and, if
found, load any modules that claim support for that device:vendor tuple?  Though
that might break in the case of uio, if there are separate driver modules that
support native hardware and uio access.

I ended up writing a script that went the other way.
First look at the hardware and load VFIO if IOMMU is available.
Then look for special driver needed for Xen and HyperV
Lastly fallback to loading igb_uio if no VFIO and PCI device present.

In other words it is a system not driver issue.

That's partly right, yes.
But you need some information which are specific to the drivers and
we should try to embed them for three usages:
	- give more info the user (without digging in the doc)
	- replace info in some external system scripts harder to maintain
	- prepare for hotplug

Some PMDs do not use UIO or VFIO at all,
However, I agree that the requirement
	(uio & igb_uio) | (uio & uio_pci_generic) | (vfio & vfio_pci)
- and even the VFIO noiommu case - could be translated into a simple
flag, let's say "generic_device_mapping"
(unfortunately "queue_mapping" doesn't exist).

The other interesting point from Fiona is to show that this information is
device-related (not general for the whole driver). So we should add a device
parameter in the macro with the ability to set a wildcard.