Re: [dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2016-09-01 10:41, Stephen Hemminger:
> Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Thu, Sep 01, 2016 at 12:55:27PM +0000, Trahe, Fiona wrote:
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> > > > On 08/31/2016 03:27 PM, Neil Horman wrote:  
> > > > > 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.