Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

From: Frederic Weisbecker
Date: Tue Jan 09 2018 - 11:04:02 EST


2018-01-09 14:36 UTC+01:00, Dmitry Safonov <dima@xxxxxxxxxx>:
> Warning: Not merge-ready
>
> I. Current workflow of ksoftirqd.
> Softirqs are processed in the context of ksoftirqd iff they are
> being raised very frequently. How it works:
> do_softirq() and invoke_softirq() deffer pending softirq iff
> ksoftirqd is in runqueue. Ksoftirqd is scheduled mostly in the
> end of processed softirqs if 2ms were not enough to process all
> pending softirqs.
>
> Here is pseudo-picture of the workflow (for simplicity on UMP):
> ------------- ------------------ ------------------
> | ksoftirqd | | User's process | | Softirqs |
> ------------- ------------------ ------------------
> Not scheduled Running
> |
> o------------------------o
> |
> __do_softirq()
> |
> 2ms & softirq pending?
> Schedule ksoftirqd
> |
> Scheduled o------------------------o
> |
> o--------------------o
> |
> Running Scheduled
> |
> o--------------------o
> |
> Not scheduled Running
>
> Timegraph for the workflow,
> dash (-) means ksoftirqd not scheduled;
> equal(=) ksoftirqd is scheduled, a softirq may still be pending
>
> Pending softirqs
> | | | | | | | | |
> v v v v | | | | v
> Processing o-----o | | | | o--o
> softirqs | | | | | | | |
> | | | | | | | |
> | | | | | | | |
> Userspace o-o o=========o | | | | o----o o---------o
> <-2ms-> | | | | | |
> | v v v v |
> Ksoftirqd o----------o
>
> II. Corner-conditions.
> During testing of commit [1] on some non-mainstream driver,
> I've found that due to platform specifics, the IRQ is being
> raised too late (after softirq has been processed).

I'm a bit confused about that part. I would expect the softirq to be
raised by the IRQ.
So I guess in this scenario the softirq is raised by something else
and you expect the upcoming IRQ to handle the softirq, right? (sorry
I'm not used to networking code).

Thanks.

> In result softirqs steal time from userspace process, leaving
> it starving for CPU time and never/rarely scheduling ksoftirqd: