netdev - Re: [PATCH net-next 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1de4ef51-dbe8-4d7e-0e43-9e92773cf52b@intel.com>
Date:   Tue, 29 May 2018 13:46:39 -0700
From:   "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To:     Michael Chan <michael.chan@...adcom.com>, davem@...emloft.net
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/3] net: Add support to configure SR-IOV VF
 minimum and maximum queues.

On 5/29/2018 1:18 AM, 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 tx queues available to the VF.
>
> o max_tx_queues - Maximum but not necessarily guaranteed tx queues
>    available to the VF.
>
> o min_rx_queues - Guaranteed rx queues available to the VF.
>
> o max_rx_queues - Maximum but not necessarily guaranteed rx queues
>    available to the VF.
>
> The "ip link set" command will subsequently be patched to support the new
> operation to set the above parameters.
>
> After the admin. makes a change to the above parameters, the corresponding
> VF will have a new range of channels to set using ethtool -L.  The VF may
> have to go through IF down/up before the new queues will take effect.  Up
> to the min values are guaranteed.  Up to the max values are possible but not
> guaranteed.
>
> Signed-off-by: Michael Chan <michael.chan@...adcom.com>
> ---
>   include/linux/if_link.h      |  4 ++++
>   include/linux/netdevice.h    |  6 ++++++
>   include/uapi/linux/if_link.h |  9 +++++++++
>   net/core/rtnetlink.c         | 32 +++++++++++++++++++++++++++++---
>   4 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
> index 622658d..8e81121 100644
> --- a/include/linux/if_link.h
> +++ b/include/linux/if_link.h
> @@ -29,5 +29,9 @@ struct ifla_vf_info {
>   	__u32 rss_query_en;
>   	__u32 trusted;
>   	__be16 vlan_proto;
> +	__u32 min_tx_queues;
> +	__u32 max_tx_queues;
> +	__u32 min_rx_queues;
> +	__u32 max_rx_queues;
>   };
>   #endif /* _LINUX_IF_LINK_H */
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 8452f72..17f5892 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1023,6 +1023,8 @@ struct dev_ifalias {
>    *      with PF and querying it may introduce a theoretical security risk.
>    * int (*ndo_set_vf_rss_query_en)(struct net_device *dev, int vf, bool setting);
>    * int (*ndo_get_vf_port)(struct net_device *dev, int vf, struct sk_buff *skb);
> + * int (*ndo_set_vf_queues)(struct net_device *dev, int vf, int min_txq,
> + *			    int max_txq, int min_rxq, int max_rxq);

Isn't ndo_set_vf_xxx() considered a legacy interface and not planned to be extended?
Shouldn't we enable this via ethtool on the port representor netdev?