In message <1gu15kf.bfmneizhtq2vM%manu@netbsd.org>,
Emmanuel Dreyfus writes:


>If I use blocking I/O with send(2) and a PPPoE connectivity, send(2)
>have to sleep when the interface queue gets full.

Balderdash.  To quote, as fair use, the relevant portion of the SUSv3
spec for send(2), which you cited in support of this harebrained idea:

    [...]	
    Successful completion of a call to send() does not guarantee delivery
    of the message. A return value of -1 indicates only locally-detected
    errors.

    If space is not available at the sending socket to hold the
    message to be transmitted, and the socket file descriptor does not
    have O_NONBLOCK set, send() shall block until space is available. 
    space is not available
    [...]	

Note where it say "*space [...] at the sending socket*". Nothing about
space at any implementation- or protocol-specific lower layers".

Note also the comment about a successful send at the socket layer
*not* guaranteeing delivery.  What you want is not, repeat *not*,
required by SUSv3, or by any implementation of the BSD sockets API
that I've ever seen or used.


As I said to Christos: there's no *point* tryng to make delivery of
packets to the NIC overly "reliable", when the NIC or the network can,
and will, and does drop those packets when it so chooses.  Doing what
you suggest will strongly and adversely affect NetBSD's networking
performance, and the perception of NetBSD in the networking community,
and inevitably in the wider community. And I tell that you three times.
The networking community has a well-known bludgeon for this class of
design mistakes; it's called the end-to-end argument. The paper is
available at http://www.reed.com/Papers/EndtoEnd.html.



Emmanuel, why don't you tell us what your actual problem is, and see
if we can help you with it, instead of suggesting ideas which are
well-known in the relevant field to be bad ideas, or incorrect (though
100% sincere, I am sure) claims that these bad ideas are somehow
mandated by standards?