netdev - Re: [PATCH net-next RFC 1/3] net: Add support to configure SR-IOV VF minimum and maximum queues.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACKFLimr=A-nDXniiBH5+JrWyW0sENPr6FK6z8FLQaDdo55hVQ@mail.gmail.com>
Date:   Wed, 9 May 2018 19:32:43 -0700
From:   Michael Chan <michael.chan@...adcom.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Or Gerlitz <gerlitz.or@...il.com>,
        David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next RFC 1/3] net: Add support to configure SR-IOV VF
 minimum and maximum queues.

On Wed, May 9, 2018 at 6:10 PM, Jakub Kicinski
<jakub.kicinski@...ronome.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.