On Wed, May 9, 2018 at 6:10 PM, Jakub Kicinski <jakub.kicin...@netronome.com> wrote: > On Wed, 9 May 2018 17:22:50 -0700, Michael Chan wrote: >> On Wed, May 9, 2018 at 4:15 PM, Jakub Kicinski wrote: >> > On Wed, 9 May 2018 07:21:41 -0400, Michael Chan wrote: >> >> VF Queue resources are always limited and there is currently no >> >> infrastructure to allow the admin. on the host to add or reduce queue >> >> resources for any particular VF. With ever increasing number of VFs >> >> being supported, it is desirable to allow the admin. to configure queue >> >> resources differently for the VFs. Some VFs may require more or fewer >> >> queues due to different bandwidth requirements or different number of >> >> vCPUs in the VM. This patch adds the infrastructure to do that by >> >> adding IFLA_VF_QUEUES netlink attribute and a new .ndo_set_vf_queues() >> >> to the net_device_ops. >> >> >> >> Four parameters are exposed for each VF: >> >> >> >> o min_tx_queues - Guaranteed or current tx queues assigned to the VF. >> > >> > This muxing of semantics may be a little awkward and unnecessary, would >> > it make sense for struct ifla_vf_info to have a separate fields for >> > current number of queues and the admin-set guaranteed min? >> >> The loose semantics is mainly to allow some flexibility in >> implementation. Sure, we can tighten the definitions or add >> additional fields. > > I would appreciate that, if others don't disagree. I personally don't > see the need for flexibility (AKA per-vendor behaviour) here, quite the > opposite, min/max/current number of queues seems quite self-explanatory. > > Or at least don't allow min to mean current? Otherwise the API gets a > bit asymmetrical :(
Sure, will do. > >> > Is there a real world use case for the min value or are you trying to >> > make the API feature complete? >> >> In this proposal, these parameters are mainly viewed as the bounds for >> the queues that each VF can potentially allocate. The actual number >> of queues chosen by the VF driver or modified by the VF user can be >> any number within the bounds. > > Perhaps you have misspoken here - these are not allowed bounds, right? > min is the guarantee that queues will be available, not requirement. > Similar to bandwidth allocation. > > IOW if the bounds are set [4, 16] the VF may still choose to use 1 > queue, event thought that's not within bounds. Yes, you are absolutely right. The VF can allocate 1 queue. Up to min is guaranteed. Up to max is not guaranteed.
