[dpdk-dev] [PATCH] igb_uio: cap max VFs at 7 to reserve one for PF

[Ananyev, Konstantin]

Hi Bruce,

>> > However, even with that, I would suggest that any limit should be possible to
>> override. It's entirely possible that someone max actually want to reserve the
>> full number of VFs, either because they don't want to use the NIC on the host at
>> all, or because they are happy to use a VF on the host instead. Module
>> parameter to allow override might work - and information on it could be added
>> to the error message when we limit the VFs inside the driver.
>> 
>> It's been a while since I've looked at this, but my recollection is
>> the PF must be there (basic mailbox handling, for example).
>> 
>> Would you rather a simple warning message as a hint?

>I'm not sure about the PF still needing to be there or not - I'm not an expert in that area, so you may indeed be right. 
>However, as for this patch, I'd probably be ok for now with a version that queried the max_vfs and limited based on that. If in >future we do need to add an override it should be trivial to add later-on.

I don't think it is a right way to put all this logic into the kernel module:
igb_uio doesn't know how many queues user-space PF plans to use for itself.
In your example: 16 queues in total, 7 VFsx2queues = 14 queues, 2 queues left to PF.
But then user-space PF decides it needs 4 queues and we we would hit the same problem again. 

I think, that to fix that issue properly we need to do that in userspace PMD.
After rte_eth_dev_init(), we should know how many queues that device has in total, and how many of them are reserved for VFs.
So at rte_eth_dev_configure() we can add a check that number of requested queues doesn't exceed max_queues - vf_reserved_queues and make rte_eth_dev_configure() to fail, if it does.  

Konstantin