Hello!

quoted text
> 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.

This is kind of obvious. It is just description of softnet.


quoted text
> once we forget about 'hardirq contexts run with irqs disabled', _there 
> is just no technological point for softirqs_. They are an unnecessary 
> abstraction!

The first paragraph describes softirq, nothing else.

I have already understood when you say "technological",
you mean "terminological". "softirq" is just a term to describe
"softnet" workflow in an intelligible way. Call it from inside
irq handler, rather than in irq_exit, this changes _NOTHING_.

I understood that you describe original pre-historic
softnet model. You just want to replace softirq run at irq_exit
with an explicit soft{net,scsi,whatever}_call, which could
execute immediately or can be queued for later. I hope I am wrong,
because this is... mmm... not a progress.


quoted text
> -rt, local_bh_disable() is a NOP there. How is it done?
...
quoted text
> Are we talking about the very same thing perhaps, just from a different 
> angle? ;-)

When talking about softnet, yes.

No, when talking about "implementing non-reentrancy via another,
more flexible mechanism". We are not on the same page.
I am afraid even the books are different. :-)

I need to think about this and really read -rt code, this sounds so crazy
that it can be even correct.

Timeout, we are far out of topic anyway.

Alexey
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/