> Subject: Re: [Patch v3] net: mana: Batch ringing RX queue doorbell on receiving > packets > > On Sun, 2023-07-02 at 20:18 +0000, Long Li wrote: > > > > > > > > > Subject: Re: [Patch v3] net: mana: Batch ringing RX > > > > > > > > > queue doorbell on receiving packets > > > > > > > > > > > > > > > > > > On Fri, 30 Jun 2023 20:42:28 +0000 Long Li wrote: > > > > > > > > > > > > > > > > > > > > > 5.15 and kernel 6.1. (those > > > > > > > > > > > > > > > > > > > > > kernels are longterm) They need > > > > > > > > > > > > > > > > > > > > > this fix to achieve the > > > > > > > > > > > > > > > > > > > > > performance target. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why can't they be upgraded to get that > > > > > > > > > > > > > > > > > performance target, and all the other > > > > > > > > > > > > > > > > > goodness that those kernels have? We > > > > > > > > > > > > > > > > > don't normally backport new features, > > > > > > > > > > > > > > > > > right? > > > > > > > > > > > > > > > > > > > > > > > > > > I think this should be considered as a fix, not > > > > > > > > > > > > > a new feature. > > > > > > > > > > > > > > > > > > > > > > > > > > MANA is designed to be 200GB full duplex at the > > > > > > > > > > > > > start. Due to lack of hardware testing > > > > > > > > > > > > > capability at early stage of the project, we > > > > > > > > > > > > > could only test 100GB for the Linux driver. When > > > > > > > > > > > > > hardware is fully capable of reaching designed > > > > > > > > > > > > > spec, this bug in the Linux driver shows up. > > > > > > > > > > > > > > > > > > That part we understand. > > > > > > > > > > > > > > > > > > If I were you I'd try to convince Greg and Paolo that > > > > > > > > > the change is small and significant for user experience. > > > > > > > > > And answer Greg's question why upgrading the kernel past > > > > > > > > > 6.1 is a challenge in your environment. > > > > > > > > > > I was under the impression that this patch was considered to be > > > > > a feature, not a bug fix. I was trying to justify that the > > > > > "Fixes:" tag was needed. > > > > > > > > > > I apologize for misunderstanding this. > > > > > > > > > > Without this fix, it's not possible to run a typical workload > > > > > designed for 200Gb physical link speed. > > > > > > > > > > We see a large number of customers and Linux distributions > > > > > committed on 5.15 and 6.1 kernels. They planned the product > > > > > cycles and certification processes around these longterm kernel > > > > > versions. It's difficult for them to upgrade to newer kernel > > > > > versions. > > I think there are some misunderstanding WRT distros and stable kernels. > (Commercial) distros will backport the patch as needed, regardless such patch > landing in the 5.15 upstream tree or not. Individual users running their own > vanilla 5.15 kernel can't expect performance improvement landing there. > > All in all I feel undecided. I would endorse this change going trough net-next > (without the stable tag). I would feel less torn with this change targeting -net > without the stable tag. Targeting -net with the stable tag sounds a bit too much to > me. > > Cheers, > Paolo I'm sending this patch to net-next without stable tag. Thanks, Long
