> As for efficiency, I agree that the per-packet send overhead will be
> larger. I'm not sure it'll be large enough to become a problem, though.
yes it is probably constant work to find the first sleeping
socket on the queue and issue a wakeup.
> > 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.
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.
cheers
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
