From: Piotr Raczynski <piotr.raczynski@intel.com>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: <intel-wired-lan@lists.osuosl.org>, <netdev@vger.kernel.org>,
<michal.swiatkowski@intel.com>, <shiraz.saleem@intel.com>,
<sridhar.samudrala@intel.com>, <jesse.brandeburg@intel.com>,
<aleksander.lobakin@intel.com>, <lukasz.czapnik@intel.com>
Subject: Re: [PATCH net-next v2 0/8] ice: support dynamic interrupt allocation
Date: Wed, 22 Mar 2023 19:40:41 +0100 [thread overview]
Message-ID: <ZBtLqdU8aCKxaHDr@nimitz> (raw)
In-Reply-To: <ec5c3cf4-49b6-32fc-d7cb-06410d6497da@intel.com>
On Wed, Mar 22, 2023 at 10:33:31AM -0700, Jacob Keller wrote:
>
>
> On 3/22/2023 9:25 AM, 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)
> >
>
> The other option would have been to make ice_vf_lib.h have a no-op
> function that always returned NULL, since we generally would know that
> there are no VF ctrl VSI if CONFIG_PCI_IOV is disabled.
>
> But I'm ok with it being in ice_lib.c too.
>
> Thanks,
> Jake
Thanks, that makes more sense, a little bit too hasty here.
next prev parent reply other threads:[~2023-03-22 18:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-22 16:25 [PATCH net-next v2 0/8] ice: support dynamic interrupt allocation Piotr Raczynski
2023-03-22 16:25 ` [PATCH net-next v2 1/8] ice: move interrupt related code to separate file Piotr Raczynski
2023-03-22 16:25 ` [PATCH net-next v2 2/8] ice: use pci_irq_vector helper function Piotr Raczynski
2023-03-22 16:25 ` [PATCH net-next v2 3/8] ice: use preferred MSIX allocation api Piotr Raczynski
2023-03-22 16:25 ` [PATCH net-next v2 4/8] ice: refactor VF control VSI interrupt handling Piotr Raczynski
2023-03-22 16:25 ` [PATCH net-next v2 5/8] ice: remove redundant SRIOV code Piotr Raczynski
2023-03-22 16:25 ` [PATCH net-next v2 6/8] ice: add individual interrupt allocation Piotr Raczynski
2023-03-22 16:25 ` [PATCH net-next v2 7/8] ice: track interrupt vectors with xarray Piotr Raczynski
2023-03-22 16:25 ` [PATCH net-next v2 8/8] ice: add dynamic interrupt allocation Piotr Raczynski
2023-03-22 17:33 ` [PATCH net-next v2 0/8] ice: support " Jacob Keller
2023-03-22 18:40 ` Piotr Raczynski [this message]
2023-03-22 19:03 ` Keller, Jacob E
2023-03-22 19:37 ` Jakub Kicinski
2023-03-22 20:05 ` Jacob Keller
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=ZBtLqdU8aCKxaHDr@nimitz \
--to=piotr.raczynski@intel.com \
--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=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).