From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH net-next 1/3] net: Add support to configure SR-IOV VF minimum and maximum queues. Date: Wed, 30 May 2018 15:36:07 -0700 Message-ID: <20180530153607.3f09d765@cakuba> References: <1527581920-3778-1-git-send-email-michael.chan@broadcom.com> <1527581920-3778-2-git-send-email-michael.chan@broadcom.com> <1de4ef51-dbe8-4d7e-0e43-9e92773cf52b@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "Samudrala, Sridhar" , David Miller , Netdev To: Michael Chan Return-path: Received: from mail-it0-f66.google.com ([209.85.214.66]:37783 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753619AbeE3Wg3 (ORCPT ); Wed, 30 May 2018 18:36:29 -0400 Received: by mail-it0-f66.google.com with SMTP id l6-v6so12256542iti.2 for ; Wed, 30 May 2018 15:36:29 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 30 May 2018 00:18:39 -0700, Michael Chan wrote: > On Tue, May 29, 2018 at 11:33 PM, Jakub Kicinski wrote: > > At some points you (Broadcom) were working whole bunch of devlink > > configuration options for the PCIe side of the ASIC. The number of > > queues relates to things like number of allocated MSI-X vectors, which > > if memory serves me was in your devlink patch set. In an ideal world > > we would try to keep all those in one place :) > > Yeah, another colleague is now working with Mellanox on something similar. > > One difference between those devlink parameters and these queue > parameters is that the former are more permanent and global settings. > For example, number of VFs or number of MSIX per VF are persistent > settings once they are set and after PCIe reset. On the other hand, > these queue settings are pure run-time settings and may be unique for > each VF. These are not stored as there is no room in NVRAM to store > 128 sets or more of these parameters. Indeed, I think the API must be flexible as to what is persistent and what is not because HW will certainly differ in that regard. And agreed, queues may be a bit of a stretch here, but worth a try. > Anyway, let me discuss this with my colleague to see if there is a > natural fit for these queue parameters in the devlink infrastructure > that they are working on. Thank you!