From: Stephen Hemminger <shemminger@osdl.org>
To: linux-kernel@vger.kernel.org
Subject: Re: Read/Write multiple network FDs in a single syscall context switch?
Date: Fri, 17 Nov 2006 13:45:29 -0800 [thread overview]
Message-ID: <20061117134529.544d67b9@freekitty> (raw)
In-Reply-To: 5A09CDB9FC09B1478DF679F4C698D1DB5CA2D5@johnleehooker.bluenote.local
On Fri, 17 Nov 2006 16:40:30 -0500
"Marc Snider" <msnider@bluenotenetworks.com> wrote:
> I've searched long and hard prior to posting here, but have been unable to locate a kernel mechanism providing the ability to read or write multiple FDs in a single userspace to kernel context switch.
>
> We've got a userspace network application that uses epoll to wait for packet arrival and then reads a single frame off of dozens of separate FDs (sockets), operates on the payload and then forwards along by writing to dozens of other separate FDs (sockets). At high loads we invariably have many dozens of socket FDs to read and write.
>
> If 50 separate frames are received on 50 separate sockets then we are at present doing 50 separate reads and then 50 separate writes, thus resulting in over a hundred distinct (and seemingly unnecessary) user to kernel space and kernel to user space context switches. Is there a mechanism I've missed which allows many network FDs to be read or written in a single syscall? For example, something analogous to the recv() and send() calls but instead providing a vector for the parameters and return value?
>
> I picture something like:
>
> ssize_t *recvMultiple(int *s, void **buf, size_t *len, int *flags) and
> ssize_t *sendMultiple(int *s, void **buf, size_t *len, int *flags)
>
>
> The user would have to be careful about not using blocking sockets with these types of multiple FD operations, but it seems to me that such a kernel mechanism would allow a user space process to eliminate dozens or even hundreds of unnecessary context switches when servicing multiple network FDs... The cycle savings for an application like ours would be huge. I am confused about why I've been unable to locate such a mechanism considering the perceived performance advantages and ubiquitous nature of user applications that service many network FDs...
>
> If it's not too much trouble then I'd appreciate if those answering could CC: me on any responses.
>
>
> Regards,
>
> Marc Snider
> msnider@bluenotenetworks.com
No there is no API like this. You will have all sorts of problems to consider like
what if there is no data on some of the sockets, or you are flow blocked or lots of
other issues. If the data is all the same then why not use multicast?
--
Stephen Hemminger <shemminger@osdl.org>
next prev parent reply other threads:[~2006-11-17 21:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-17 21:40 Read/Write multiple network FDs in a single syscall context switch? Marc Snider
2006-11-17 21:45 ` Stephen Hemminger [this message]
2006-11-18 4:19 ` Willy Tarreau
[not found] <5A09CDB9FC09B1478DF679F4C698D1DB0482C9@johnleehooker.bluenote.local>
2006-11-18 4:24 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061117134529.544d67b9@freekitty \
--to=shemminger@osdl.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox