On Mon, Mar 28, 2005 at 08:48:37PM -0800, Jonathan Stone wrote:
> Well if you say so, then I fear I may be wrong; but I thought the PR
> and the entire ENOBUFS case was for non-blocking mode?

Manu's first message to tech-kern@ said "blocking I/O".  I just
looked at the PR, and it does, indeed, say "non blocking I/O".
The test program, however, doesn't set non-blocking I/O.  So I see
the source of the confusion here.  I think we should be clear in
the remainder of this discussion if we're talking about blocking
or non-blocking mode.

> If you want your application to work in real networks, not dedicated
> "toy" networks like the NETBLT experiments[1] then your applications
> have to be able to recover from drop and from congestion.

In these cases, I would not, personally, be using blocking I/O, and
probably not using UDP.

> packets is at the sending hosts.  There's no point investing network
> resources in sending a packet halfway across the network, just to have
> the packet dropped due to congestion in any case; the network is

I agree fully with that.  And if you can tell the application that
the packet was dropped, it has a chance to attempt to compensate
in some appropriate manner.  In non-blocking mode, we can return
EAGAIN and to me that means, "there is congestion--back off".  As
you imply--it doesn't really matter where the congestion is.  In
blocking mode, as I see it, you're basically telling the kernel
that you want the kernel to make a best effort at sending the data
and you're willing to wait for it to do so.

Now, in a general purpose network situation, I see two reasonable
points of view, and I think this is what we are discussing:

	1) The kernel should behave as it does now because someone
	   writing a simple application could easily jam up the
	   network by simply sending a stream of datagrams.

	2) The kernel should sleep on a blocking I/O send when the
	   queue is full because that is consistent with the
	   semantics for blocking I/O.

In either case, we can slam the network.  Your suggestion to sleep
until the queue is completely drained seems like it would address
the congestion issue to some degree, although my intuition says
that it would lead to a really bursty traffic pattern.

Personally, I lean toward maintaining the semantics of blocking I/O
if it isn't overly complicated to do so, but I'm somewhat ambivalent.

> >In non-blocking mode, by all means, return EAGAIN/EWOULDBLOCK if
> >it would block.
> 
> Back again to an earlier paragraph; isn't it ENOBUFS in that case?

It may.  I have not looked at what we actually do.

> Is this confusion between blocking and non-blocking the reason Christos
> and I were talking past each other earlier?

That was my thought, yes.

> I mention that because to me, it's far, far more signficinat than
> whatever changes we may or may not make to our UDP code.

Thank you for spelling that out clearly.  I see that Manu changed
the DESCR.

-allen

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