Messages in this thread | | | Subject | Re: [PATCH 0/3] softirq: uncontroversial change | From | Paolo Abeni <> | Date | Thu, 20 Apr 2023 22:23:14 +0200 |
| |
On Thu, 2023-04-20 at 19:41 +0200, Eric Dumazet wrote: > On Thu, Apr 20, 2023 at 7:24 PM Paolo Abeni <pabeni@redhat.com> wrote: > > I would like to propose a revert of: > > > > 4cd13c21b207 softirq: Let ksoftirqd do its job > > > > the its follow-ups: > > > > 3c53776e29f8 Mark HI and TASKLET softirq synchronous > > 0f50524789fc softirq: Don't skip softirq execution when softirq thread is parking > > > > The problem originally addressed by 4cd13c21b207 can now be tackled > > with the threaded napi, available since: > > > > 29863d41bb6e net: implement threaded-able napi poll loop support > > > > Reverting the mentioned commit should address the latency issues > > mentioned by Jakub - I verified it solves a somewhat related problem in > > my setup - and reduces the layering of heuristics in this area. > > > > A refactor introducing uniform overload detection and proper resource > > control will be better, but I admit it's beyond me and anyway it could > > still land afterwards. > > > > Any opinion more then welcome! > > Seems fine, but I think few things need to be fixed first in > napi_threaded_poll() > to enable some important features that are currently in net_rx_action() only.
Thanks for the feedback.
I fear I'll miss some relevant bits.
On top of my head I think about RPS and skb_defer_free. Both should work even when napi threaded is enabled - with an additional softirq ;) Do you think we should be able to handle both inside the napi thread? Or do you refer to other features?
Thanks!
Paolo
| |