On Fri, 17 Nov 2006 22:53:26 -0500 "Marc Snider" <[EMAIL PROTECTED]> wrote:
> Sorry, I must have given the wrong impression with respect to the data. It > is not all the same. Each ingress socket is associated with an individual > egress socket and the packet data being received and transmitted is unique > across ingress/egress socket pairs... > > Guess I don't see the difficulties you alluded to below, Stephen. The > userspace app would only ask to receive on sockets where there was already > known data available as per Epoll reporting. I also think it a reasonable > constraint to require in this multiple FD operation case that all sockets are > mandated as nonblocking, thus a zero or some other unique return value could > be provided for each socket that would have blocked in lieu of EWOULDBLOCK. > > Write sockets would only be written to when data was available, so there > would be no ambiguity on write operations. Again, if the request could not > be satisfied due to socket buffer overflow or other aberration a nonblocking > return code would ensue. > > If all socket FDs referenced were required to be nonblocking then I'm having > difficulty understanding how circumstances would differ for a vectorized > recvMultiple() or sendMultiple() operation when contrasted with doing > multiple individual recv() and/or send() calls on N nonblocking sockets... > > Forgive me if I'm missing something. It seems to me that the bang for the > buck in exponentially reducing the number of context switches required for a > userspace application to service many network FDs makes a great deal of sense > here.... > > Regards, > Marc Snider > [EMAIL PROTECTED] > You forget on Linux system calls are cheap, unlike other OS's. A poll/select followed by a receive is going to be as fast as any recv_any() type interface. Unless you can reduce the number of copies from kernel to user (or vice versa) there is no point to inventing yet another network interface. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
