From: Piotr Raczynski <piotr.raczynski@intel.com>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: michal.swiatkowski@intel.com, netdev@vger.kernel.org,
jesse.brandeburg@intel.com, intel-wired-lan@lists.osuosl.org,
shiraz.saleem@intel.com
Subject: Re: [Intel-wired-lan] [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.
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
WARNING: multiple messages have this Message-ID (diff)
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: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-22 16:25 [Intel-wired-lan] [PATCH net-next v2 0/8] ice: support dynamic interrupt allocation Piotr Raczynski
2023-03-22 16:25 ` Piotr Raczynski
2023-03-22 16:25 ` [Intel-wired-lan] [PATCH net-next v2 1/8] ice: move interrupt related code to separate file Piotr Raczynski
2023-03-22 16:25 ` Piotr Raczynski
2023-03-22 16:25 ` [Intel-wired-lan] [PATCH net-next v2 2/8] ice: use pci_irq_vector helper function Piotr Raczynski
2023-03-22 16:25 ` Piotr Raczynski
2023-03-22 16:25 ` [Intel-wired-lan] [PATCH net-next v2 3/8] ice: use preferred MSIX allocation api Piotr Raczynski
2023-03-22 16:25 ` Piotr Raczynski
2023-03-22 16:25 ` [Intel-wired-lan] [PATCH net-next v2 4/8] ice: refactor VF control VSI interrupt handling Piotr Raczynski
2023-03-22 16:25 ` Piotr Raczynski
2023-03-22 16:25 ` [Intel-wired-lan] [PATCH net-next v2 5/8] ice: remove redundant SRIOV code Piotr Raczynski
2023-03-22 16:25 ` Piotr Raczynski
2023-03-22 16:25 ` [Intel-wired-lan] [PATCH net-next v2 6/8] ice: add individual interrupt allocation Piotr Raczynski
2023-03-22 16:25 ` Piotr Raczynski
2023-03-22 16:25 ` [Intel-wired-lan] [PATCH net-next v2 7/8] ice: track interrupt vectors with xarray Piotr Raczynski
2023-03-22 16:25 ` Piotr Raczynski
2023-03-22 16:25 ` [Intel-wired-lan] [PATCH net-next v2 8/8] ice: add dynamic interrupt allocation Piotr Raczynski
2023-03-22 16:25 ` Piotr Raczynski
2023-03-22 17:33 ` [Intel-wired-lan] [PATCH net-next v2 0/8] ice: support " Jacob Keller
2023-03-22 17:33 ` Jacob Keller
2023-03-22 18:40 ` Piotr Raczynski [this message]
2023-03-22 18:40 ` Piotr Raczynski
2023-03-22 19:03 ` [Intel-wired-lan] " Keller, Jacob E
2023-03-22 19:03 ` Keller, Jacob E
2023-03-22 19:37 ` [Intel-wired-lan] " Jakub Kicinski
2023-03-22 19:37 ` Jakub Kicinski
2023-03-22 20:05 ` [Intel-wired-lan] " Jacob Keller
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=intel-wired-lan@lists.osuosl.org \
--cc=jacob.e.keller@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=michal.swiatkowski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=shiraz.saleem@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.