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
