• glebius@
• olivier@
• rrs@
• rscheff@
• thj@
• tuexen@
• Cheng C

• tuexen@ wants to discuss the behaviour of recv(fd, NULL, 0, 0) for SOCK_DGRAM sockets. tuexen@ will bring this up on the net@ mailing list.
• It was discussed whether the TCP_LOG socket option should be inherited from the listener. jtl@ said that this should be the case, but interaction with the sysctl-variable net.inet.tcp.bb.log_auto_ratio should be taken into account. tuexen@ will look at it and add jtl@ as a reviewer.
• netstat does not support reading connection information from a core file anymore. tuexen@ will document that in the man-page.
• rscheff@ wants feedback on: D21117. tuexen@ will review it.
• glebius@ asks whether it makes sense to improve the TCP timer precision. tuexen@ states that this is very useful for testing purposes. glebius@ will provide a patch to tuexen@ for testing and tuexen@ will provide feedback, if such a patch us useful for FreeBSD in general. This applies to the default stack only, not the the RACK or BBR stack, which used HPTS for timers.
• At least for testing purposes (packetdrill) it would be good to have LRO support for tun interfaces. tuexen@ suggested to generalize LRO to not depend on an Ethernet header being present. gallatin@ prefers to not make the LRO code more complex, since it most likely will impact the performance. tjh@ has D37437 under review, which allows the tun interface to add an Ethernet header. tuexen@ will test this to see if it can also be used to enable LRO for the tun interface. This seems netmap specific. tuexen@ will consider to use tap interfaces in packetdrill.
• tuexen@ asked why running sysctl net.inet.tcp.udp_tunneling_port=9811 in a loop ends up with EBUSY. tuexen@ will send information about the code path taken to trigger EBUSY and glebius@ will have a quick look if he can figure out what is going on.

• rscheff@ is improving AccECN code: D36303.
• D23230 is implementing ECN++.
• D28822 improves PRR, needs some cleanup.
• tuexen@ wants to write a tool which dumps the BBLog information of a TCP endpoint from a life system or a core. Using kvm_read() has drawbacks as glebius@ pointed out, using a python kgdb script may be an alternative. An alternative is to write a python kgdb script which pumps data into tcplog_dumper. This would allow to minimize code duplication. @glebius will try to work on this soon.

09 February 2023 @ 1500 UTC