Re: ping: sendto: No buffer space available

[David Laight <david%l8s.co.uk@localhost>]

On Sun, Oct 09, 2011 at 05:36:06PM -0700, Erik Fair wrote:
> 
> On second thought, the kernel should block on that condition, unless the 
> user code has explicitly set a non-blocking flag (and thus indicated its 
> ability/willingness to handle the "queue is full" error with appropriate 
> behavior). Otherwise, we're simply going to get naive application code 
> that bangs away at sending without appropriate exponential backoff.
> 
> Yes, this is an API change. Alternative suggestions welcome.

I'm not entirely sure there are many applications that would be
badly affected by making datagram sends blockable due to network
flow control.

While the network stack is allowed to drop requests, I don't think it
should unless it gets caught in a very tight corner.
I'm sure ICLs SYSV network stack did block under these conditions.

There are some problems in actually implementing flow control through
multiplexors (like UDP and IP) down to the network driver.
The STREAMS style queue limits doesn't work well as it is particularly
difficult to evenly (or unevenly if wanted) share the resource.

One scheme we've used quite successfully it to limit the number of
messages allocated by each source (in this case that would be a socket).
The lower layers have to ensure they don't discard the original message.
But it is very simple, and only needs a small structure for each
allocating entity.
Since you can allow the 'count' to go above its nominal limit, the
check can be right at the start of the syscall - with the allocation
itself always suceeding.

Receive data can be re-assigned to the receivers socket/queue - removing
it from the resorce count of the network interface itself.

This might be better than the current global limit on mbufs for normal
workloads.  It can also give some idea about where the buffers are
queued (or lost).

        David

-- 
David Laight: david%l8s.co.uk@localhost