Luigi Rizzo wrote:
> > > All in all I think this approach would only help a bit if
> > > if you were allowed to queue in the socket buffer
> > > (on which you can think of having some control, because you either
> > > opened the fd yourself or you inherited it from some parent),
> > > in addition to the device queue.
> >
> > Could you explain this a little more? I think I know where you're going
> > with this, but I'm not sure :-)
>
> i think i meant you want to buffer your overflowing packets in the
> socket buffer, and use them as an extension of the ipq. Basically
> once the interface queue is full, you create a list of socket buffers
> waiting for a transmit, then when a slot in the ifqueue becomes empty
> you fill it up with the next pkt from next the socket buffer
> without having to wakeup the process associated with it unless
> you pass the lowwater mark.
This is more elaborate that what I was proposing. I was only thinking about
queueing one UDP packet per socket when blocking, so there are no socket
buffer queueing issues. I think queueing more than one could be more
problematic for some applications, since it might decouple the write call
returning from the actual send time of the packet too much.
It'd be interesting to make the number of packets allowed to be queued in a
UDP socket buffer a parameter, though...
> But again, it is quite a bit of work to put all this code together,
> and you end up with something that other systems do not have so
> when you want to write portable code you still have to handle
> the old behaviour as well in userland.
Yes. But we're talking research here :-) (E.g. once UDP blocking is there,
I can use it to do other neat things in the networking stack...)
Lars
--
Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
S/MIME Cryptographic Signature
