From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: netdev@vger.kernel.org, Joe Damato <jdamato@fastly.com>,
kuba@kernel.org, intel-wired-lan@lists.osuosl.org,
davem@davemloft.net
Subject: Re: [Intel-wired-lan] [next-queue 1/3] i40e: Store the irq number in i40e_q_vector
Date: Thu, 6 Oct 2022 15:06:30 +0200 [thread overview]
Message-ID: <Yz7S1oUaxN7AtsY/@boxer> (raw)
In-Reply-To: <94e40ec4-fed8-5d91-54a0-b96bb21c6b9e@intel.com>
On Wed, Oct 05, 2022 at 12:37:19PM -0700, Jesse Brandeburg wrote:
> On 10/5/2022 11:40 AM, Joe Damato wrote:
>
> > > If you're really wanting to reorganize these structs I'd prefer a bit more
> > > diligent effort to prove no inadvertent side effects (like maybe by turning
> > > up the interrupt rate and looking at perf data while receiving 512 byte
> > > packets. The rate should remain the same (or better) and the number of cache
> > > misses on these structs should remain roughly the same. Maybe a seperate
> > > patch series?
> >
> > I honestly did think that reorganizing the struct was probably out of scope
> > of this change, so if you agree so I'll drop this change from the v2 and
> > keep the original which adds irq_num to the end of the struct.
>
> I agree, especially in these routines, doing simple, explainable/observable
> changes is best.
Jesse, I recall now that this weird qvector struct layout is also the case
on ice driver. Maybe we should document it somewhere/somehow (or even
explain) to avoid touching it? I believe that not only me would have such
a knee-jerk reaction to try to pack it.
_______________________________________________
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: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Joe Damato <jdamato@fastly.com>,
<intel-wired-lan@lists.osuosl.org>, <netdev@vger.kernel.org>,
<kuba@kernel.org>, <davem@davemloft.net>,
<anthony.l.nguyen@intel.com>
Subject: Re: [next-queue 1/3] i40e: Store the irq number in i40e_q_vector
Date: Thu, 6 Oct 2022 15:06:30 +0200 [thread overview]
Message-ID: <Yz7S1oUaxN7AtsY/@boxer> (raw)
In-Reply-To: <94e40ec4-fed8-5d91-54a0-b96bb21c6b9e@intel.com>
On Wed, Oct 05, 2022 at 12:37:19PM -0700, Jesse Brandeburg wrote:
> On 10/5/2022 11:40 AM, Joe Damato wrote:
>
> > > If you're really wanting to reorganize these structs I'd prefer a bit more
> > > diligent effort to prove no inadvertent side effects (like maybe by turning
> > > up the interrupt rate and looking at perf data while receiving 512 byte
> > > packets. The rate should remain the same (or better) and the number of cache
> > > misses on these structs should remain roughly the same. Maybe a seperate
> > > patch series?
> >
> > I honestly did think that reorganizing the struct was probably out of scope
> > of this change, so if you agree so I'll drop this change from the v2 and
> > keep the original which adds irq_num to the end of the struct.
>
> I agree, especially in these routines, doing simple, explainable/observable
> changes is best.
Jesse, I recall now that this weird qvector struct layout is also the case
on ice driver. Maybe we should document it somewhere/somehow (or even
explain) to avoid touching it? I believe that not only me would have such
a knee-jerk reaction to try to pack it.
next prev parent reply other threads:[~2022-10-06 13:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-05 8:31 [Intel-wired-lan] [next-queue 0/3] i40e: Add an i40e_napi_poll tracepoint Joe Damato
2022-10-05 8:31 ` Joe Damato
2022-10-05 8:31 ` [Intel-wired-lan] [next-queue 1/3] i40e: Store the irq number in i40e_q_vector Joe Damato
2022-10-05 8:31 ` Joe Damato
2022-10-05 10:29 ` [Intel-wired-lan] " Maciej Fijalkowski
2022-10-05 10:29 ` Maciej Fijalkowski
2022-10-05 17:00 ` [Intel-wired-lan] " Joe Damato
2022-10-05 17:00 ` Joe Damato
2022-10-05 18:25 ` [Intel-wired-lan] " Jesse Brandeburg
2022-10-05 18:25 ` Jesse Brandeburg
2022-10-05 18:40 ` [Intel-wired-lan] " Joe Damato
2022-10-05 18:40 ` Joe Damato
2022-10-05 19:37 ` [Intel-wired-lan] " Jesse Brandeburg
2022-10-05 19:37 ` Jesse Brandeburg
2022-10-06 13:06 ` Maciej Fijalkowski [this message]
2022-10-06 13:06 ` Maciej Fijalkowski
2022-10-05 8:31 ` [Intel-wired-lan] [next-queue 2/3] i40e: i40e_clean_tx_irq returns work done Joe Damato
2022-10-05 8:31 ` Joe Damato
2022-10-05 8:45 ` [Intel-wired-lan] " Paul Menzel
2022-10-05 8:45 ` Paul Menzel
2022-10-05 10:46 ` Maciej Fijalkowski
2022-10-05 10:46 ` Maciej Fijalkowski
2022-10-05 17:50 ` [Intel-wired-lan] " Joe Damato
2022-10-05 17:50 ` Joe Damato
2022-10-05 18:33 ` [Intel-wired-lan] " Jesse Brandeburg
2022-10-05 18:33 ` Jesse Brandeburg
2022-10-05 18:47 ` [Intel-wired-lan] " Joe Damato
2022-10-05 18:47 ` Joe Damato
2022-10-05 8:31 ` [Intel-wired-lan] [next-queue 3/3] i40e: Add i40e_napi_poll tracepoint Joe Damato
2022-10-05 8:31 ` Joe Damato
2022-10-05 10:27 ` [Intel-wired-lan] " Maciej Fijalkowski
2022-10-05 10:27 ` Maciej Fijalkowski
2022-10-05 17:56 ` [Intel-wired-lan] " Joe Damato
2022-10-05 17:56 ` Joe Damato
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=Yz7S1oUaxN7AtsY/@boxer \
--to=maciej.fijalkowski@intel.com \
--cc=davem@davemloft.net \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jdamato@fastly.com \
--cc=jesse.brandeburg@intel.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
/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.