Skip to content

Polling mode  #4797

@inevity

Description

@inevity

Why need poll mode?
For the tokio core loop, for current thread runtime, which is the block_on, we can have two way to loop, one just use the event notify mechanic which tokio current use, one way use the busy polling mode to drive system forward.
Of course, the mio /epoll/tokio::threadpark now just are proper to use the event notify mechanics.
But mio:epoll/threadpark also support park_yield(epollwait with timeout = 0 and threadpark:unpark() ) which is not blocking the thread, with that, we can continuely park_yield, let the cpu busy. Of course, for the net fop read,write, this is not the true poll mode(for which, we need continue read/write with noblock flag), but from the loop viewpoint, we can think it as poll mode. And in some case, maybe improve the tokio performance, because it just avoid thread upark() syscall(for epoll, avoid the eventfd write).
Even more, We will later can easily add another true poll mode source which not use the event mechinainc ,such as io_uring polling poller, dpdk user space polling mode poller in the poll mode code.

In fact, the concept is same as the seastar poll mode.
And if we intruduce it to tokio, later iouring polling mode will not been need to wrap in the mio event system, just through tokio polling mode to drive iouring.

Another reseason for the pollmode, is that for some rmda network, 40G network , some PM device, pollmode is to improve latency against throuhtput.

See tokio polling mode support

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-tokioArea: The main tokio crateC-feature-requestCategory: A feature request.M-runtimeModule: tokio/runtime

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions