Re: Read/Write multiple network FDs in a single syscall contextswitch?

[Stephen Hemminger]

On Fri, 17 Nov 2006 22:53:26 -0500
"Marc Snider" <msnider@xxxxxxxxxxxxxxxxxxxx> 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
> msnider@xxxxxxxxxxxxxxxxxxxx
> 

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/