Andi Kleen wrote:
>
> Ion Badulescu <ionut@cs.columbia.edu> writes:
> > I'll state again: if data (UDP or otherwise) is lost after sendto()
> > returns success but before it hits the wire, something is BROKEN in that
> > IP stack.
>
> Your proposal would break select(). It would require UDP sendmsg to block
> when the TX queue is full. Most applications using select do
> not send the socket non blocking. If they select for writing and the
> kernel signals the socket writable they expect not to block in the write.
> As long as the only thing controlling the blocking is the per socket
> send buffer that works out as long as the application is careful enough
> not to fill its send buffer. If you would put the TX queue into the
> blocking equation too this cannot be guaranteed anymore because the TX queue
> is shared between all local processes and even forwarding. You would
> get random blocking on select based applications, breaking them.
I don't see the problem. So sendto() blocks if there is no room on the socket
buffer. Fine. So if there's room on the socket buffer we take the packet and
put in on the buffer, and sendto() returns.
Now, for each socket we've got a buffer of packets that want to get onto the
device driver tx queue. So we use some kind of algorithm to pick which packets
to move from the group of socket buffers to the device driver tx queue. If the
app calls sendto() before there is space in the socket buffer, then sendto()
blocks. select() should return whether or not there is space in the socket
buffer. Eventually, every packet that gets put into a socket buffer makes it
out onto the wire. Congestion is dealt with by leaving packets in the socket
buffers until they can be guaranteed a spot in the device tx queue. I assume we
would try and add it to the tx queue, and remove it from the socket buffer if
the add succeeds.
I just don't see why sendto() would accept the packet and then later on it gets
dropped.
Chris
-- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:58 EST