>> The point of the discussion is the behavior of send() on a full
>> interface.  If an application decided to flood the network, it is
>> not the job of the kernel to stop it (in UDP).
> I'm confused.  Aren't we talking about one way of the kernel avoiding
> a flood vs another?  One way is to just drop; the packet isn't sent,
> so no flooding.  The other way is to wait, so the packet isn't sent
> until there's room on the net, so no flooding. ???

No.  If the application keeps trying to send, if it keeps at least one
packet in the transmit queue at all times, it will be pumping stuff out
at full wire speed (or as close to as things like collision backoff &c
will permit).  The point under discussion, as I see it, is whether to
do this by silently dropping send attempts into a full queue, noisily
dropping them (our current behaviour), blocking them, or what.  Unless
the kernel blocks them and sleeps gratuitously long - past the point of
queue drain - it isn't actually preventing flooding, it isn't keeping
userland from redlining the interface.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B