On Fri, Mar 31, 2023 at 10:20 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Fri, 31 Mar 2023 08:48:07 +0800 Jason Xing wrote: > > On Fri, Mar 31, 2023 at 12:23 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > > On Thu, 30 Mar 2023 17:59:46 +0800 Jason Xing wrote: > > > > I'm wondering for now if I can update and resend this patch to have a > > > > better monitor (actually we do need one) on this part since we have > > > > touched the net_rx_action() in the rps optimization patch series? > > > > Also, just like Jesper mentioned before, it can be considered as one > > > > 'fix' to a old problem but targetting to net-next is just fine. What > > > > do you think about it ? > > > > > > Sorry, I don't understand what you're trying to say :( > > > > Previously this patch was not accepted because we do not want to touch > > softirqs (actually which is net_rx_action()). Since it is touched in > > the commit [1] in recent days, I would like to ask your permission: > > could I resend this patch to the mailing list? I hope we can get it > > merged. > > > > This patch can be considered as a 'fix' to the old problem. It's > > beneficial and harmless, I think :) > > The not touching part was about softirqs which is kernel/softirq.c, > this patch was rejected because it's not useful. But...but time_squeeze here is really vague and it doesn't provide any useful information to those user-side tools, which means we cannot conclude anything from this output if we have to trace back to the history of servers. Right now, time_squeeze looks abandoned but many applications still rely on it. It's not proper :( Thanks, Jason
