netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Piotr Raczynski <piotr.raczynski@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	michal.swiatkowski@intel.com, shiraz.saleem@intel.com,
	jacob.e.keller@intel.com, sridhar.samudrala@intel.com,
	jesse.brandeburg@intel.com, aleksander.lobakin@intel.com,
	lukasz.czapnik@intel.com
Subject: Re: [PATCH net-next v3 0/8] ice: support dynamic interrupt allocation
Date: Wed, 29 Mar 2023 14:35:51 +0300	[thread overview]
Message-ID: <20230329113551.GN831478@unreal> (raw)
In-Reply-To: <20230323122440.3419214-1-piotr.raczynski@intel.com>

On Thu, Mar 23, 2023 at 01:24:32PM +0100, Piotr Raczynski wrote:
> This patchset reimplements MSIX interrupt allocation logic to allow dynamic
> interrupt allocation after MSIX has been initially enabled. This allows
> current and future features to allocate and free interrupts as needed and
> will help to drastically decrease number of initially preallocated
> interrupts (even down to the API hard limit of 1). Although this patchset
> does not change behavior in terms of actual number of allocated interrupts
> during probe, it will be subject to change.
> 
> First few patches prepares to introduce dynamic allocation by moving
> interrupt allocation code to separate file and update allocation API used
> in the driver to the currently preferred one.
> 
> Due to the current contract between ice and irdma driver which is directly
> accessing msix entries allocated by ice driver, even after moving away from
> older pci_enable_msix_range function, still keep msix_entries array for
> irdma use.
> 
> Next patches refactors and removes redundant code from SRIOV related logic
> as it also make it easier to move away from static allocation scheme.
> 
> Last patches actually enables dynamic allocation of MSIX interrupts. First,
> introduce functions to allocate and free interrupts individually. This sets
> ground for the rest of the changes even if that patch still allocates the
> interrupts from the preallocated pool. Since this patch starts to keep
> interrupt details in ice_q_vector structure we can get rid of functions
> that calculates base vector number and register offset for the interrupt
> as it is equal to the interrupt index. Only keep separate register offset
> functions for the VF VSIs.
> 
> Next, replace homegrown interrupt tracker with much simpler xarray based
> approach. As new API always allocate interrupts one by one, also track
> interrupts in the same manner.
> 
> Lastly, extend the interrupt tracker to deal both with preallocated and
> dynamically allocated vectors and use pci_msix_alloc_irq_at and
> pci_msix_free_irq functions. Since not all architecture supports dynamic
> allocation, check it before trying to allocate a new interrupt.
> 
> As previously mentioned, this patchset does not change number of initially
> allocated interrupts during init phase but now it can and will likely be
> changed.
> 
> Patch 1-3 -> move code around and use newer API
> Patch 4-5 -> refactor and remove redundant SRIOV code
> Patch 6   -> allocate every interrupt individually
> Patch 7   -> replace homegrown interrupt tracker with xarray
> Patch 8   -> allow dynamic interrupt allocation
> 
> Change history:
> v1 -> v2:
> - ice: refactor VF control VSI interrupt handling
>   - move ice_get_vf_ctrl_vsi to ice_lib.c (ice_vf_lib.c depends on
>     CONFIG_PCI_IOV)
> v2 -> v3:
> - ice: refactor VF control VSI interrupt handling
>   - revert v2 change and add no-op function in case of CONFIG_PCI_IOV=n
> - ice: add dynamic interrupt allocation
>   - fix commit message
> 
> Piotr Raczynski (8):
>   ice: move interrupt related code to separate file
>   ice: use pci_irq_vector helper function
>   ice: use preferred MSIX allocation api
>   ice: refactor VF control VSI interrupt handling
>   ice: remove redundant SRIOV code
>   ice: add individual interrupt allocation
>   ice: track interrupt vectors with xarray
>   ice: add dynamic interrupt allocation
> 

Thanks,
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>

      parent reply	other threads:[~2023-03-29 11:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23 12:24 [PATCH net-next v3 0/8] ice: support dynamic interrupt allocation Piotr Raczynski
2023-03-23 12:24 ` [PATCH net-next v3 1/8] ice: move interrupt related code to separate file Piotr Raczynski
2023-03-26 13:34   ` Simon Horman
2023-04-21  5:36   ` [Intel-wired-lan] " Pucha, HimasekharX Reddy
2023-03-23 12:24 ` [PATCH net-next v3 2/8] ice: use pci_irq_vector helper function Piotr Raczynski
2023-03-26 13:35   ` Simon Horman
2023-04-21  5:41   ` [Intel-wired-lan] " Pucha, HimasekharX Reddy
2023-03-23 12:24 ` [PATCH net-next v3 3/8] ice: use preferred MSIX allocation api Piotr Raczynski
2023-03-26 13:35   ` Simon Horman
2023-04-21  5:45   ` [Intel-wired-lan] " Pucha, HimasekharX Reddy
2023-03-23 12:24 ` [PATCH net-next v3 4/8] ice: refactor VF control VSI interrupt handling Piotr Raczynski
2023-03-26 13:36   ` Simon Horman
2023-03-23 12:24 ` [PATCH net-next v3 5/8] ice: remove redundant SRIOV code Piotr Raczynski
2023-03-26 13:36   ` Simon Horman
2023-04-06  9:50     ` [Intel-wired-lan] " Romanowski, Rafal
2023-03-23 12:24 ` [PATCH net-next v3 6/8] ice: add individual interrupt allocation Piotr Raczynski
2023-03-26 13:18   ` Simon Horman
2023-03-28 16:16     ` Piotr Raczynski
2023-04-21  5:48   ` [Intel-wired-lan] " Pucha, HimasekharX Reddy
2023-03-23 12:24 ` [PATCH net-next v3 7/8] ice: track interrupt vectors with xarray Piotr Raczynski
2023-03-26 13:19   ` Simon Horman
2023-03-28 16:12     ` Piotr Raczynski
2023-04-21  5:53   ` [Intel-wired-lan] " Pucha, HimasekharX Reddy
2023-03-23 12:24 ` [PATCH net-next v3 8/8] ice: add dynamic interrupt allocation Piotr Raczynski
2023-03-26 13:37   ` Simon Horman
2023-04-21  5:55   ` [Intel-wired-lan] " Pucha, HimasekharX Reddy
2023-03-29 11:35 ` Leon Romanovsky [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230329113551.GN831478@unreal \
    --to=leon@kernel.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=lukasz.czapnik@intel.com \
    --cc=michal.swiatkowski@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=piotr.raczynski@intel.com \
    --cc=shiraz.saleem@intel.com \
    --cc=sridhar.samudrala@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).