linux-kernel - Re: Read/Write multiple network FDs in a single syscall context switch?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20061117202440.267a9c25@localhost.localdomain>
Date:	Fri, 17 Nov 2006 20:24:40 -0800
From:	Stephen Hemminger <shemminger@...l.org>
To:	"Marc Snider" <msnider@...enotenetworks.com>
Cc:	<linux-kernel@...r.kernel.org>
Subject: Re: Read/Write multiple network FDs in a single syscall context
 switch?

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

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