• TransportProtocols
• 01October2026

Attendees

• Nick Banks
• cc@
• crest@
• dch@
• glebius@
• msvoelker@
• pouria@
• tuexen@

Ongoing Short Term Projects

• 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. tuexen@ has implemented LRO support for the tap interfaces. packetdrill support will be committed soon.
• tuexen@ will add tests for handling RST ACK segments in all states and test the base, RACK and BBR stack.

• Make use of vtnet checksum offloading in bhyve: D51688. Reviews appreciated. pouria reviewed D51289, but some advice needed on specific circumstances. glebius@ suggested to have ae@ and melifaro@ brought in to give advice how to handle the specific case.

• It was discussed how to deal with dependencies of kernel modules used in the ktest infrastructure. glebius@ will provide a proof of concept for the solution discussed: don't autoload modules being tested by the test modules and allow test modules to fail loading in case some conditions are not met.

• Timo wants feedback D56564. glebius@ will review.

• Approaches to be able to unit test the TCP host cache were discussed. rscheff@ will implement that functionality.

• How to progress eLog (D56979 and D57309)? Since these patches contain work done with AI, it was suggested to wait until the FreeBSD project has an AI policy.

• glebius@ is working on improving the loopback performance.

• When reviewing D59454, tuexen@ found two issues with the host cache:

  1. When storing the RTT and RTTVAR, different stacks use different units. It was discussed and suggested to use always usecs in the host cache. tuexen@ will work on it.

  2. Information of an endpoint is stored when the endpoint is freed. This is much too late in case of TIMEWAIT. tuexen@ suggested to do it when the FIN is acked and will provide a patch for review.

• crest@ implemented if_pair and this uses a thread pool. This thread pool idea seems to be usable in other contexts. glebius@ suggests improving netisr to be able to improve several parts in the networking code. Also taskq could be used if a more general scope is intended.

• It was discussed how precise a description of a TCP bug should be in an upcoming EN. The conclusion was to describe how to detect that the problem happened and how to mitigate it.
• pouria@ asked about how to document the netlink API.

• cc@ wants feedback on D59357 and D59669 which improves TCP CC modules. tuexen@ will take a look.

• cc@ wants feedback on D59907 which improves siftr. tuexen@ will look at it.

Ongoing Longer Term Projects

• It was discussed how checksum offloading should be done in general. glebius@ suggested to not deal with the transmit side in the network stack at all, but do this in the NIC drivers. It was agreed to be a good architecture, but it requires to touch all NIC drivers. It was mentioned that this could be done incrementally and it sounds like a good idea. Notes for this plan are in ChecksumOffloading. Timo Völker and tuexen@ will work on a prototype implementation. A prototype from Timo is available at offload_prototype.

• Now the RACK and the BBR stack are compiled by default in head. The BBR and the RACK stack will continue to coexists. We discussed if the RACK stack could be made the default and what should drive this decision. tuexen@ will reach out to the mailing list to ask people to test the RACK stack and provide feedback. In January, we will look again at the decision process based on the feedback we got. Feedback received:
  • You need to compile in the TCPHPTS. It is a loadable module now, thanks to glebius@.
  • RACK is on the loopback interface slower than the base stack (CPU limited). olivier@ has a script to test combinations of stacks and CC modules.

  • A problem with RACK and pf, which couldn't be reproduced by olivier@. tuexen@ has an idea what is going wrong and will provide a patch to the reporter for testing.D43769 fixes this, but adds some instructions to the code path.

  • When using mbuf queueing, some dtrace static probes are missed. Fixed.
  • There is a performance regression by just loading the HPTS module. This is fixed.
• It was discussed that it would be a good idea to move the freebsd stack from ticks to micro seconds.

• rscheff@ is improving AccECN code: D36303. rrs@ will review it and implement it for the rack stack. Also the interaction between LRO and AccECN++ has to be taken into account. D42563 further adds the support of ACKofACK.

• D23230 is implementing ECN++. rrs@ will review it.

• 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. thj@ has an initial implementation at tcplog_dumper.

• The handling on ECN with TSO by NICs was discussed. tuexen@ will add a configuration option for various Intel NICs to make the TSO behavior configurable, rscheff@ will make in the TCP stack configurable wether classical ECN or AccECN will use TSO. tuexen@ wants feedback on D44258 and D44259.

• rgrimes@ reports that FreeBSD using the default parameters can not saturate a Gigabit pipe with a delay used by recent access technologies. He is proposing to bump up some default values.

• glebius@ will re-activate D35199 which speeds up finding bugs.

• tuexen@ will add fast open tests to the FreeBSD testsuite. This might require some additional counters.

• cc@ wants review of D47130. Possible ways of breaking up tcp_do_segment() were discussed. No agreement was reached. cc@ will try several ways and bring the alternatives back for further discussion.

Next Meeting

15 October 2026 @ 1500 UTC using FreeBSDTCPCall