Masakazu Kitajo
2018-11-19 01:12:57 UTC
Hi all,
Here is a result of ATS QUIC Hackathon at Tokyo.
We couldn't make many code changes, but we were able to find out a cause of
performance issue. This is a big win, which we couldn't make without this
hackathon.
## Input
Possible reasons of low performance:
- Send / receive packets one by one with sendmsg and recvmsg
- WRITE_READY event is scheduled like a spin
- Multiple copy happen during sending data
### Why WRITE_READY is scheduled by NetVC itself?
Because there is only one FD
-> Delayed bind should resolve the WRITE_READY spin issue
### Why not sendmmsg?
A concern raised on the last hackathon was that sendmmsg works like all or
nothing
-> sendmsg returns the number of packets sent, so doesn't need to re-send
all the packets
-> Use sendmmsg as well as recvmmsg
### Use ET_SSL for encryption?
Encryption might block the thread
-> ET_NET does it for HTTPS, so it would not be a problem
-> We should increase a number of ET_NET if it really matters
### Less copy with IOBufferBlock?
It was the consensus of the last hackathon but many things changed
-> We should stick with the plan if possible
## Discussion
### What should we work on?
- Performance issue has priority
- H3 and QPACK have priority too but too big for Hackathon timeframe
## Hack
### Performance issue
Found that WRITE_READY_INTERVAL is one of causes.
-> connect + bind should remove this interval
We still see ~30ms delays before sending packets in the queue.
### Memory allocator
Since we have many classes for QUIC, we would need a lot of allocators.
Use of jemalloc would be an option but not sure if we really want it.
Use of class allocators for QUIC frames look unnecessary (#4621).
### Generate random token (#4494)
PR #4598 was created.
### sendmmsg / recvmmsg
sendmsg_x and recvmsg_x seem like not public system calls.
Need to find alternatives.
### Ports for QUIC (#4410)
Not exactly for the QUIC issue but PR #4600 was created.
### H2 crash issue (#4504)
The mutex for H2ConnectionState is released too early.
PR #4504 was created.
## Other
According to the minutes of IETF103, RFC won't be published until July.
We can still aim 9.0 release if there are no big changes on the specs, but
9.1 is more plausible.
Thanks,
Masakazu
Here is a result of ATS QUIC Hackathon at Tokyo.
We couldn't make many code changes, but we were able to find out a cause of
performance issue. This is a big win, which we couldn't make without this
hackathon.
## Input
Possible reasons of low performance:
- Send / receive packets one by one with sendmsg and recvmsg
- WRITE_READY event is scheduled like a spin
- Multiple copy happen during sending data
### Why WRITE_READY is scheduled by NetVC itself?
Because there is only one FD
-> Delayed bind should resolve the WRITE_READY spin issue
### Why not sendmmsg?
A concern raised on the last hackathon was that sendmmsg works like all or
nothing
-> sendmsg returns the number of packets sent, so doesn't need to re-send
all the packets
-> Use sendmmsg as well as recvmmsg
### Use ET_SSL for encryption?
Encryption might block the thread
-> ET_NET does it for HTTPS, so it would not be a problem
-> We should increase a number of ET_NET if it really matters
### Less copy with IOBufferBlock?
It was the consensus of the last hackathon but many things changed
-> We should stick with the plan if possible
## Discussion
### What should we work on?
- Performance issue has priority
- H3 and QPACK have priority too but too big for Hackathon timeframe
## Hack
### Performance issue
Found that WRITE_READY_INTERVAL is one of causes.
-> connect + bind should remove this interval
We still see ~30ms delays before sending packets in the queue.
### Memory allocator
Since we have many classes for QUIC, we would need a lot of allocators.
Use of jemalloc would be an option but not sure if we really want it.
Use of class allocators for QUIC frames look unnecessary (#4621).
### Generate random token (#4494)
PR #4598 was created.
### sendmmsg / recvmmsg
sendmsg_x and recvmsg_x seem like not public system calls.
Need to find alternatives.
### Ports for QUIC (#4410)
Not exactly for the QUIC issue but PR #4600 was created.
### H2 crash issue (#4504)
The mutex for H2ConnectionState is released too early.
PR #4504 was created.
## Other
According to the minutes of IETF103, RFC won't be published until July.
We can still aim 9.0 release if there are no big changes on the specs, but
9.1 is more plausible.
Thanks,
Masakazu