On Saturday 06 August 2005 02:33, David S. Miller wrote:
> You can't call into the networking packet input path from
> hardware interrupt context, it simply is not allowed.
>
> And that's the context in which netif_rx() gets called.
Duh. I assumed we already were in softirq context here (but with 20-20
hindsight, that would be stupid extra work).
> That is why netif_rx() just queues, and schedules a software
> interrupt in which the netif_receive_skb() call gets made.
So then there is no choice but to throttle the per-cpu ->input_pkt queues.
The throttling code is already there, I just need to repurpose it slightly.
That is, netif_rx will be something like:
if (queue->input_pkt_queue.qlen <= netdev_max_backlog &&
reserve_available(skb->dev)) {
<deliver the packet>
<return>
}
<drop the packet>
This will needlessly drop the very last packet allocated from reserve, a
slight wastage, but obvious correctness is more important at this point.
The only purpose of this extra throttling is to avoid having to include the
entire netdev_max_backlog (default 300) in the network block IO packet
reserve. That would be 1.2 MB per interface, perhaps a little too much to
withdraw from the general memory pool. I am thinking that even a single
packet's worth of reserve is enough to make _probabilistic_ forward progress,
but then we run a high risk of being DOSed by non-blockio traffic, and
through will be crippled just when it hurts most. So the right reserve size
is a compromise between the single element required to make (probabilistic)
forward progress and the number that will almost never fill up the
->input_pkt queue under zero atomic memory conditions. I guess 50-100
packets in reserve is about right, reduce it for larger MTU, increase it for
higher interface speed.
Question: it looks to me as if a given network device interrupt is always
routed to the same CPU. Can I rely on that? If so, I can do the reserve
throttling strictly per-cpu, if not, then a slightly messier calculation is
necessary.
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
