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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
