The new meeting link is working fine. If you have not, look at the updated calendar entry for this meeting.
rrs@ has merged his BBR code internally so now that's being tested at NF. Still another 3-6 months of testing to be done.
hiren@ identified a receive side problem in the previous drop of BBR but this is now addressed
jtl@ mentions that NF are developing an in kernel system for grabbing the TCP data. gnn@ asks for a code diff.
hiren@ asks whether or not the hardware pacing mechanisms can lower the CPU overhead involved in the current BBR implementation. jtl@ responds that yes, hardware pacing support would help
drew@ says that the current packet pacing API, though not perfect, will work with both Mellanox and Chelsio. This may require a firmware upgrade for Mellanox cards in the Sentex lab.
gnn@ has been adding documentation to packetdrill and this is in the freebsd-net/packetdrill repo on github
rstone@ has a capture that shows that a close is failing on FIN/ACK fight. hiren@ points out that this is fixed in 11 and HEAD but does not have a specific revision. tuexen@asks for a trace.
tuexen@ asks where the MTU is stored in IPv6 when an MTU too big is received. bz@ points out that this is only stored in the host cache. gnn@ does not think that this is in the restored route cache.
ae@ has put up a large diff relating, mostly, to IPSec, but which touches other parts of the network stack: https://reviews.freebsd.org/D9352
rrs@ found an issue in autoscaling. This is a logic error in the default stack. rrs@ will upstream a fix shortly.
the modularization of the stack does give us the ability to more easily review a single function but has resulted in a great deal of code duplication. It's time to start harmonizing the code base again. Everyone who cares needs to review the currently split out stack to see if we can agree on common APIs.
glebius@ has split the socket system into a traditional socket and a listen socket. The listen socket has less state and now has fewer locks. It should improve the number of connections the system is capable of accepting. glebius@ will post a Phabricator.