* Alexey Kuznetsov <[email protected]> wrote:
> > as i said above (see the underlined sentence), hardirq contexts
> > already run just fine with hardirqs enabled.
>
> RENTRANCY PROTECTION! If does not matter _how_ they run, it matters
> what context they preempt and what that context has to make to prevent
> that preemption. [...]
again, there is no reason why this couldnt be done in a hardirq context.
If a hardirq preempts another hardirq and the first hardirq already
processes the 'softnet work', you dont do it from the second one but
queue it with the first one. (into the already existing
sd->completion_queue for tx work or queue->poll_list for rx work) It
would be a simple additional flag in softnet_data.
once we forget about 'hardirq contexts run with irqs disabled', _there
is just no technological point for softirqs_. They are an unnecessary
abstraction!
once we concede that point, reentrancy protection does not have to be
done via local_bh_disable(). For example we run just fine without it in
-rt, local_bh_disable() is a NOP there. How is it done? By controlling
execution of the _workflow_ that a softirq does. By implementing
non-reentrancy via another, more flexible mechanism. (and by carefully
fixing a few _other_, non-workflow assumptions that softnet does/did,
such as the per-cpu-ness of softnet_data.)
Are we talking about the very same thing perhaps, just from a different
angle? ;-)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
