[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Yz7S1oUaxN7AtsY/@boxer>
Date: Thu, 6 Oct 2022 15:06:30 +0200
From: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
To: Jesse Brandeburg <jesse.brandeburg@...el.com>
CC: Joe Damato <jdamato@...tly.com>,
<intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
<kuba@...nel.org>, <davem@...emloft.net>,
<anthony.l.nguyen@...el.com>
Subject: Re: [next-queue 1/3] i40e: Store the irq number in i40e_q_vector
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.
Powered by blists - more mailing lists