lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
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