[PATCH v5 0/4] fast poll multishot mode

[PATCH v5 0/4] fast poll multishot mode

[Hao Xu]

From: Hao Xu <howeyxu@tencent.com>

Let multishot support multishot mode, currently only add accept as its
first consumer.
theoretical analysis:
  1) when connections come in fast
    - singleshot:
              add accept sqe(userspace) --> accept inline
                              ^                 |
                              |-----------------|
    - multishot:
             add accept sqe(userspace) --> accept inline
                                              ^     |
                                              |--*--|

    we do accept repeatedly in * place until get EAGAIN

  2) when connections come in at a low pressure
    similar thing like 1), we reduce a lot of userspace-kernel context
    switch and useless vfs_poll()


tests:
Did some tests, which goes in this way:

  server    client(multiple)
  accept    connect
  read      write
  write     read
  close     close

Basically, raise up a number of clients(on same machine with server) to
connect to the server, and then write some data to it, the server will
write those data back to the client after it receives them, and then
close the connection after write return. Then the client will read the
data and then close the connection. Here I test 10000 clients connect
one server, data size 128 bytes. And each client has a go routine for
it, so they come to the server in short time.
test 20 times before/after this patchset, time spent:(unit cycle, which
is the return value of clock())
before:
  1930136+1940725+1907981+1947601+1923812+1928226+1911087+1905897+1941075
  +1934374+1906614+1912504+1949110+1908790+1909951+1941672+1969525+1934984
  +1934226+1914385)/20.0 = 1927633.75
after:
  1858905+1917104+1895455+1963963+1892706+1889208+1874175+1904753+1874112
  +1874985+1882706+1884642+1864694+1906508+1916150+1924250+1869060+1889506
  +1871324+1940803)/20.0 = 1894750.45

(1927633.75 - 1894750.45) / 1927633.75 = 1.65%

v1->v2:
 - re-implement it against the reworked poll code

v2->v3:
 - fold in code tweak and clean from Jens
 - use io_issue_sqe rather than io_queue_sqe, since the former one
   return the internal error back which makes more sense
 - remove io_poll_clean() and its friends since they are not needed

v3->v4:
 - move the accept multishot flag to the proper patch
 - typo correction
 - remove improperly added signed-off-by

v4->v5:
 - address some email account issue..


Hao Xu (4):
  io_uring: add IORING_ACCEPT_MULTISHOT for accept
  io_uring: add REQ_F_APOLL_MULTISHOT for requests
  io_uring: let fast poll support multishot
  io_uring: implement multishot mode for accept

 fs/io_uring.c                 | 94 +++++++++++++++++++++++++++--------
 include/uapi/linux/io_uring.h |  5 ++
 2 files changed, 79 insertions(+), 20 deletions(-)


base-commit: 0a194603ba7ee67b4e39ec0ee5cda70a356ea618
-- 
2.25.1

Re: [PATCH v5 0/4] fast poll multishot mode

[Hao Xu]

Sorry for polluting the list, not sure why the cover-letter isn't
wired with the other patches..

Regards,
Hao

On 5/8/22 23:37, Hao Xu wrote:
> From: Hao Xu <howeyxu@tencent.com>
> 
> Let multishot support multishot mode, currently only add accept as its
> first consumer.
> theoretical analysis:
>    1) when connections come in fast
>      - singleshot:
>                add accept sqe(userspace) --> accept inline
>                                ^                 |
>                                |-----------------|
>      - multishot:
>               add accept sqe(userspace) --> accept inline
>                                                ^     |
>                                                |--*--|
> 
>      we do accept repeatedly in * place until get EAGAIN
> 
>    2) when connections come in at a low pressure
>      similar thing like 1), we reduce a lot of userspace-kernel context
>      switch and useless vfs_poll()
> 
> 
> tests:
> Did some tests, which goes in this way:
> 
>    server    client(multiple)
>    accept    connect
>    read      write
>    write     read
>    close     close
> 
> Basically, raise up a number of clients(on same machine with server) to
> connect to the server, and then write some data to it, the server will
> write those data back to the client after it receives them, and then
> close the connection after write return. Then the client will read the
> data and then close the connection. Here I test 10000 clients connect
> one server, data size 128 bytes. And each client has a go routine for
> it, so they come to the server in short time.
> test 20 times before/after this patchset, time spent:(unit cycle, which
> is the return value of clock())
> before:
>    1930136+1940725+1907981+1947601+1923812+1928226+1911087+1905897+1941075
>    +1934374+1906614+1912504+1949110+1908790+1909951+1941672+1969525+1934984
>    +1934226+1914385)/20.0 = 1927633.75
> after:
>    1858905+1917104+1895455+1963963+1892706+1889208+1874175+1904753+1874112
>    +1874985+1882706+1884642+1864694+1906508+1916150+1924250+1869060+1889506
>    +1871324+1940803)/20.0 = 1894750.45
> 
> (1927633.75 - 1894750.45) / 1927633.75 = 1.65%
> 
> v1->v2:
>   - re-implement it against the reworked poll code
> 
> v2->v3:
>   - fold in code tweak and clean from Jens
>   - use io_issue_sqe rather than io_queue_sqe, since the former one
>     return the internal error back which makes more sense
>   - remove io_poll_clean() and its friends since they are not needed
> 
> v3->v4:
>   - move the accept multishot flag to the proper patch
>   - typo correction
>   - remove improperly added signed-off-by
> 
> v4->v5:
>   - address some email account issue..
> 
> 
> Hao Xu (4):
>    io_uring: add IORING_ACCEPT_MULTISHOT for accept
>    io_uring: add REQ_F_APOLL_MULTISHOT for requests
>    io_uring: let fast poll support multishot
>    io_uring: implement multishot mode for accept
> 
>   fs/io_uring.c                 | 94 +++++++++++++++++++++++++++--------
>   include/uapi/linux/io_uring.h |  5 ++
>   2 files changed, 79 insertions(+), 20 deletions(-)
> 
> 
> base-commit: 0a194603ba7ee67b4e39ec0ee5cda70a356ea618

Re: [PATCH v5 0/4] fast poll multishot mode

[Jens Axboe]

On 5/8/22 9:43 AM, Hao Xu wrote:
> Sorry for polluting the list, not sure why the cover-letter isn't
> wired with the other patches..

Yeah not sure what's going on, but at least they are making it
through... Maybe we should base this on the
for-5.19/io_uring-alloc-fixed branch? The last patch needs to be updated
for that anyway. I'd think the only sane check there now is if it's a
multishot direct accept request, then the request must also specify
IORING_FILE_INDEX_ALLOC to ensure that we allocate descriptors.


-- 
Jens Axboe

Re: [PATCH v5 0/4] fast poll multishot mode

[Jens Axboe]

On 5/9/22 9:15 PM, Jens Axboe wrote:
> On 5/8/22 9:43 AM, Hao Xu wrote:
>> Sorry for polluting the list, not sure why the cover-letter isn't
>> wired with the other patches..
> 
> Yeah not sure what's going on, but at least they are making it
> through... Maybe we should base this on the
> for-5.19/io_uring-alloc-fixed branch? The last patch needs to be updated
> for that anyway. I'd think the only sane check there now is if it's a
> multishot direct accept request, then the request must also specify
> IORING_FILE_INDEX_ALLOC to ensure that we allocate descriptors.

Oh, and I'm assuming you added some comprehensive tests for this for
liburing? Both functionally, but also checking the cases that should
fail (like mshot + fixed without alloc, etc). When you send out the
next/final version, would be great if you could do a the same for the
liburing side.

-- 
Jens Axboe

Re: [PATCH v5 0/4] fast poll multishot mode

[Hao Xu]

在 2022/5/10 上午11:22, Jens Axboe 写道:
> On 5/9/22 9:15 PM, Jens Axboe wrote:
>> On 5/8/22 9:43 AM, Hao Xu wrote:
>>> Sorry for polluting the list, not sure why the cover-letter isn't
>>> wired with the other patches..
>>
>> Yeah not sure what's going on, but at least they are making it

It turns out that the outlook SMTP server changed the message-id and
thus messed up the thread linkchain..

>> through... Maybe we should base this on the
>> for-5.19/io_uring-alloc-fixed branch? The last patch needs to be updated
>> for that anyway. I'd think the only sane check there now is if it's a
>> multishot direct accept request, then the request must also specify
>> IORING_FILE_INDEX_ALLOC to ensure that we allocate descriptors.
> 
> Oh, and I'm assuming you added some comprehensive tests for this for
> liburing? Both functionally, but also checking the cases that should
> fail (like mshot + fixed without alloc, etc). When you send out the
> next/final version, would be great if you could do a the same for the
> liburing side.

Sure, I'll rebase it with the comments and also post liburing tests in
the next version

Regards,
Hao

>