public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexey Syrnikov <san@masterspline.net>
To: linux-kernel@vger.kernel.org
Subject: [network feature request] Optimized sys_accept and sys_connect
Date: Wed, 03 Jun 2015 04:59:00 +0300	[thread overview]
Message-ID: <556E5F64.7090708@masterspline.net> (raw)

Hello, kernel developers.

Many network server (HTTP for example) currently work in such way:

  accept -> read (once) -> write (typically once) -> close

So, this sequence can be optimized by making accept and read in one
syscall. When socket ready to accept it can already have data (delivered
in 3-rd tcp packet in 3-way handshake with SYN+ACK). Making accept and
read at once we will

1) reduce syscalls (one in place of two)
2) reduce network latancy (at least for 1 mks, it is ~1000 CPU ticks for
syscall)
The cost: new syscall and bit of code

Because some protocols requires server at first send data to connected
client, this syscall can also do accept+write. This behavior can be
switched by some flag (accept+read or accept+write). I call it
sys_accept_plus :)

The same apply to connect+write. Network client at connecting stage
already knows which HTTP request they need to send. So making connect
and write in one syscall we will

1) make one syscall (not two)
2) reduce network latency
3) send GET request with the same (in most cases single) TCP packet as
last SYN+ACK without waiting sys_write (as in separate connect and write).
Costs are same: one extra syscall and bit of code.

This is sys_connect_plus.

I did not think about error reporting (userspace code need to know when
error happens at first or second stage and some errors have same codes).

What do You think about such feature?

Alex

                 reply	other threads:[~2015-06-03  2:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=556E5F64.7090708@masterspline.net \
    --to=san@masterspline.net \
    --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