Hangout 17 May 2018
- rrs@ will provide a fix for a bug in the default stack resulting in data corruption. (ETA: June 15)
jegg broke his locking review into multiple parts. Some committed. (Still awaiting work: D14624 and D14808.)
jtl requests further input on making the default stack buildable as a module. (D11105) He is concerned this will cause pain for downstream consumers and for backporting bugs, but thinks it is the right thing to do. Please review and comment.
- After much arm-twisting, jtl@ agreed to commit this.
bz requests review for D3721.
- thj may review once bz rebases onto current head
jtl plans to commit the "progress timer" (D14993) after dealing with review feedback
thj working on adding UDP options (IETF internet-draft). In the course, he found a bug with UDP checksum calculation using the IP length instead of the UDP length. Because of hardware offload, he may need people with multiple cards to test. (UDP checksum review is D15222.)
someone else took over the in6_delayed_cksum bug (see message).
12.0 planning: what else do we need, or are we planning?
- Pacing (renamed to HPTS) is in
- TCPCB reshuffle is in
- RACK is after that (ETA: June 24)
- BBR is after that (Maybe)
- gallatin plans to commit unmapped mbufs by FreeBSD 12 code slush.
- gallatin may(?) commit kernel TLS (outbound only) by 12. Will be limited to platforms with a direct map.
Reminder: BSDCan Dev Summit working group - approved, please register (email jtl)
- mmacy: Trying to improve UDP receive performance. Next step: use concurrency toolkit (RCU) to improve INPCB hash performance. He plans to post incremental review.
mmacy: Extended discussion about higher-precision timestamps. (See D15337.) mmacy reports improvements, even when talking with a remote host that has no modifications. rrs and mtuexen raised concerns about the interaction with a low RTO timeout on one side and high delayed-ack timeout on the remote side. jtl suggests on-wire negotiation could help avoid this. mtuexen points out that the RTO/delayed-ACK interaction is the important thing to avoid (and, therefore, potentially negotiate). jtl points out that high-resolution timestamps might break 3rd-party monitoring tools that assume millisecond semantics for the timestamp field.