On Mon, Mar 28, 2005 at 10:04:47PM -0500, Christos Zoulas wrote:
> On Mar 28,  6:54pm, jonathan@dsg.stanford.edu (Jonathan Stone) wrote:
> | Thus, the question under discussion is: what should we do under
> | sustained overload (or attempts to sustain overload) of the if_snd
> | queue?  Specifically, when an app using UDP (or other unreliable
> | datagram protocols) uses non-blocking I/O to persistently overflow the
> | if_snd queue?
> | 
> | The most correct anwser is: we should drop packets.
> 
> You are not dropping packets. You are returning ENOBUFS to the application,
> and you are giving it a chance to retry.

I believe the discussion started talking about BLOCKING mode, not
non-blocking mode.  It seems to me to be more robust in general if
the kernel sleeps until there's space on the queue--when in blocking
mode.  It makes more sense from an application programming point
of view and it makes more sense from a resource utilization point
of view.  If someone's trying to fill the pipe, make 'em sleep,
don't encourage them to spin.

In non-blocking mode, by all means, return EAGAIN/EWOULDBLOCK if
it would block.

I don't see a good reason to transmit "output queue is full" back
to the application when you're in blocking mode.  And I'm not sure
when I would care *why* it would block in non-blocking mode.

Note:	I'm leaving the specific application out of this.  I'm
	leaving multicast & broadcast out of this.  On a UDP
	socket *in blocking mode*, what should the application
	see?

Since you, Jonathan, have a lot of networking experience, have
read a lot (most?) of the literature, and participated in multiple
fora, I am very interested in hearing what you have to say and
understanding how this looks from that perspective.  I understand
you have a vehement reaction to what Emmanuel proposed, but I'm
interested in the technical argument, not the vehemence.

-allen

-- 
                  Use NetBSD!  http://www.netbsd.org/