Page MenuHomeFreeBSD
Feed Advanced Search

Mon, Jul 7

cc accepted D51125: tcp: don't allow to connect a TCP/IPv6 endpoint in TIME WAIT state.

Other than the fd is not used in the test code, I am good with this change.

Mon, Jul 7, 4:31 PM

Mon, Jun 30

cc added a comment to D51090: tcp: remove an invalid KASSERT.

Thanks for the elaboration. Looks good to me now.

Mon, Jun 30, 11:20 PM
cc accepted D51090: tcp: remove an invalid KASSERT.
Mon, Jun 30, 11:20 PM
cc added a comment to D51090: tcp: remove an invalid KASSERT.

Looks I am missing the context. Given the fact that the socket is in TCPS_TIME_WAIT while switching to the default stack, was this assert a day one issue that was not test covered before? Or was this panic caused by recent changes?

Mon, Jun 30, 2:10 PM

Jun 16 2025

cc accepted D50840: tcp: cleanup timer initialisations.
Jun 16 2025, 7:46 PM
cc committed rGa2f579635f67: cc_cubic: sync to the new specification of RFC9438 for TCP CUBIC. (authored by cc).
cc_cubic: sync to the new specification of RFC9438 for TCP CUBIC.
Jun 16 2025, 4:55 PM
cc closed D49540: cc_cubic: sync to the new specification of RFC9438 for TCP CUBIC..
Jun 16 2025, 4:55 PM
cc updated the test plan for D49540: cc_cubic: sync to the new specification of RFC9438 for TCP CUBIC..
Jun 16 2025, 4:33 PM

Jun 13 2025

cc accepted D50830: tcp: fix handling of TIME WAIT for local TCP connections.
Jun 13 2025, 1:01 PM
cc accepted D50829: udp: fix local blackholing.
Jun 13 2025, 1:01 PM
cc accepted D50828: tcp: fix local blackholing.
Jun 13 2025, 12:57 PM

Jun 11 2025

cc added inline comments to D50637: tcp: allow specifying a MSL for local communications.
Jun 11 2025, 9:22 PM

May 14 2025

cc updated the test plan for D49540: cc_cubic: sync to the new specification of RFC9438 for TCP CUBIC..
May 14 2025, 4:04 PM

May 1 2025

cc accepted D49922: tcp: improve KASSERT in limited retransmit.
May 1 2025, 3:29 PM
cc updated the test plan for D49540: cc_cubic: sync to the new specification of RFC9438 for TCP CUBIC..
May 1 2025, 1:04 PM
cc updated the test plan for D49540: cc_cubic: sync to the new specification of RFC9438 for TCP CUBIC..
May 1 2025, 12:53 PM

Apr 21 2025

cc accepted D49941: netstat: fix table header alignment for -x.
Apr 21 2025, 1:16 PM

Mar 27 2025

cc updated the summary of D49540: cc_cubic: sync to the new specification of RFC9438 for TCP CUBIC..
Mar 27 2025, 7:06 PM
cc updated the summary of D49540: cc_cubic: sync to the new specification of RFC9438 for TCP CUBIC..
Mar 27 2025, 7:04 PM
cc updated the test plan for D49540: cc_cubic: sync to the new specification of RFC9438 for TCP CUBIC..
Mar 27 2025, 5:24 PM
cc requested review of D49540: cc_cubic: sync to the new specification of RFC9438 for TCP CUBIC..
Mar 27 2025, 5:20 PM

Mar 20 2025

cc accepted D48652: tcp: revert rxtshift too on a spurious timeout (RTO).
Mar 20 2025, 8:17 PM
cc accepted D49414: tcp: fix detection of bad RTOs.

This is for the fast path fix. Just want to confirm with your that a second patch may be around to improve both of the fast and slow path?

Mar 20 2025, 3:43 PM

Mar 17 2025

cc closed D49247: tcp cc: use tcp_compute_pipe() for pipe in xx_post_recovery() directly.
Mar 17 2025, 1:03 PM
cc committed rGa8d2bccb87d0: tcp cc: use tcp_compute_pipe() for pipe in xx_post_recovery() directly (authored by cc).
tcp cc: use tcp_compute_pipe() for pipe in xx_post_recovery() directly
Mar 17 2025, 1:03 PM

Mar 5 2025

cc updated the test plan for D49247: tcp cc: use tcp_compute_pipe() for pipe in xx_post_recovery() directly.
Mar 5 2025, 4:47 PM
cc requested review of D49247: tcp cc: use tcp_compute_pipe() for pipe in xx_post_recovery() directly.
Mar 5 2025, 4:45 PM

Feb 28 2025

cc closed D49047: tcp: make inflight data (pipe) calculation consistent.
Feb 28 2025, 8:56 PM
cc committed rG67787d200488: tcp: make inflight data (pipe) calculation consistent (authored by cc).
tcp: make inflight data (pipe) calculation consistent
Feb 28 2025, 8:56 PM
cc added a comment to D49047: tcp: make inflight data (pipe) calculation consistent.

Didn't see any surprising regression from my test result for this patch:
testD49047

Feb 28 2025, 8:42 PM

Feb 21 2025

cc updated the diff for D49047: tcp: make inflight data (pipe) calculation consistent.

code update based on Richard's comments

Feb 21 2025, 8:53 PM
cc added inline comments to D49047: tcp: make inflight data (pipe) calculation consistent.
Feb 21 2025, 4:07 PM
cc updated the diff for D49047: tcp: make inflight data (pipe) calculation consistent.

re-base, add a missing part and update based on Richard's comment in the meeting

Feb 21 2025, 4:01 PM

Feb 20 2025

cc committed rG7f9ef5c75fd1: cc_cubic: remove redundant code (authored by cc).
cc_cubic: remove redundant code
Feb 20 2025, 4:01 PM
cc closed D49008: cc_cubic: remove redundant code.
Feb 20 2025, 4:01 PM
cc added inline comments to D49047: tcp: make inflight data (pipe) calculation consistent.
Feb 20 2025, 3:40 PM

Feb 19 2025

cc added a comment to D49047: tcp: make inflight data (pipe) calculation consistent.

Question: why does this function returns signed value? And why some of the sackhint counters are signed?

There are several calls to tcp_compute_pipe() that did not check the V_tcp_do_newsack: 2 in tcp_output and 1 in tcp_input. Their behavior will change with revised SACK turned off. Commit message should explain why this is okay.

Feb 19 2025, 11:22 PM

Feb 18 2025

cc requested review of D49047: tcp: make inflight data (pipe) calculation consistent.
Feb 18 2025, 6:13 PM

Feb 14 2025

cc updated the summary of D49008: cc_cubic: remove redundant code.
Feb 14 2025, 4:19 PM
cc requested review of D49008: cc_cubic: remove redundant code.
Feb 14 2025, 4:15 PM

Feb 12 2025

cc committed rG6156da866e7d: cc_cubic: remove redundant calls of tcp_fixed_maxseg() (authored by cc).
cc_cubic: remove redundant calls of tcp_fixed_maxseg()
Feb 12 2025, 10:50 PM
cc closed D48967: cc_cubic: remove redundant calls of tcp_fixed_maxseg().
Feb 12 2025, 10:50 PM
cc updated the summary of D48967: cc_cubic: remove redundant calls of tcp_fixed_maxseg().
Feb 12 2025, 4:50 PM
cc requested review of D48967: cc_cubic: remove redundant calls of tcp_fixed_maxseg().
Feb 12 2025, 4:43 PM

Jan 31 2025

cc accepted D48710: tcp: remove check for condition that never happens.
Jan 31 2025, 3:10 PM

Jan 8 2025

cc added a comment to D48346: TCP RACK: don't log an uninitialized value.

Why not move the old_method: label above the stack variables' declaration? I think it may be cleaner to read.
Like this:

Jan 8 2025, 8:40 PM
cc accepted D48341: TCP BBR: remove dead code.
Jan 8 2025, 8:16 PM

Jan 6 2025

cc accepted D48323: TCP BBR: remove dead code.
Jan 6 2025, 3:20 PM

Dec 18 2024

cc accepted D48065: tcp: cleanup of nits after use of accessor tcp_get_flags.
Dec 18 2024, 5:19 PM

Dec 11 2024

cc accepted D48025: icmp.4: improve man page.
Dec 11 2024, 5:47 PM

Dec 10 2024

cc added a comment to D48001: icmp: improve INVARIANTS check.

Additional comment:

Dec 10 2024, 2:26 PM
cc accepted D48001: icmp: improve INVARIANTS check.
Dec 10 2024, 2:23 PM

Nov 25 2024

cc accepted D47713: udp: Prefer memcpy() over bcopy.
Nov 25 2024, 2:43 PM

Nov 19 2024

cc added a comment to D47474: tcp: Use segment size excluding any options for all cwnd calculations.

update:
Looks this patch has some significant reduction on fragment (data_size % MSS) > 0 out of TSO data chunks: testD47474
TSO not enabled:

versionfragment_cnt
before patch D4747431
after patch D474741
Nov 19 2024, 4:17 PM

Nov 14 2024

cc added a comment to D47474: tcp: Use segment size excluding any options for all cwnd calculations.

Well, I had the same thought - the full MSS (including options) is less frequently used, that the mss without options...

So, it would certainly be more efficient to store the MSS exkluding options in tcpcb, and calculating the MSS inkl. option space only where that is needed...

But that should a different Diff IMHO, as this one is more in the break/fix category.

Nov 14 2024, 4:36 PM
cc added inline comments to D47474: tcp: Use segment size excluding any options for all cwnd calculations.
Nov 14 2024, 4:09 PM

Nov 4 2024

cc accepted D47439: tcp: consistently set CWND to MSS in case of SYN/SYN ACK retransmissions.

I think you meant the title be:
tcp: consistently set CWND to MSS => tcp: consistently set CWND to 1
in case of SYN/SYN ACK retransmissions => in case of SYN retransmissions

Nov 4 2024, 8:59 PM

Oct 28 2024

cc accepted D43470: tcp: refactor cwnd during SACK transmissions and enable TSO.

OK. I am approving it now as my test in https://wiki.freebsd.org/chengcui/testD43470 shows some improvement. Any bug related observations can be fixed later.

Oct 28 2024, 3:42 PM

Oct 24 2024

cc added a comment to D47056: tcp: allow TSO even while RX path is unordered.

Also, please correct the SUMMARY section:

Oct 24 2024, 7:21 PM

Oct 23 2024

cc added a comment to D30155: ixgbe: Bring back accounting for tx in AIM.
In D30155#1075233, @cc wrote:

From my test result in testD30155, I didn't find any significant improvement under my eyes:

  • no significant difference in ping latency
  • no significant iperf3 performance improvement due to bad performance (3.x Gbps) in FreeBSD 15-current vs. (9.x Gbps) in stock Linux kernel 5.15.

Thanks for the results @cc. Something seems very strange with the throughput there, the main system I am testing is a xeon-d that is much less than 1/4th as powerful and can line rate both directions no issues and I also have an older 2x Xeon E5-2695 v2 (two NUMA domains) without throughput limitations. I will see if I can find my emulab credentials and take a look there, it seems like these might be 4-way NUMA machines but it is not expected to me that that would cause this magnitude of throughput issues, especially at the 10gbit data rate.

Oct 23 2024, 7:18 PM

Oct 22 2024

cc removed a reviewer for D4295: Add driver backpressure: cc.
Oct 22 2024, 8:06 PM · transport
cc added a reviewer for D4295: Add driver backpressure: cc.
Oct 22 2024, 8:05 PM · transport

Oct 21 2024

cc requested review of D47218: tcp cc: re-organize newreno functions into parts that can be re-used.
Oct 21 2024, 2:33 PM
cc requested review of D47213: cc_cubic: use newreno to emulate AIMD in TCP-friendly region.
Oct 21 2024, 11:12 AM

Oct 17 2024

cc updated the summary of D47130: tcp: remove the `goto drop` label by reusing equivalences in tcp_do_segment()..
Oct 17 2024, 10:17 PM
cc updated the diff for D47130: tcp: remove the `goto drop` label by reusing equivalences in tcp_do_segment()..

update code based on discussion

Oct 17 2024, 7:39 PM
cc added a comment to D30155: ixgbe: Bring back accounting for tx in AIM.

From my test result in testD30155, I didn't find any significant improvement under my eyes:

Oct 17 2024, 2:05 PM

Oct 16 2024

cc added a comment to D43470: tcp: refactor cwnd during SACK transmissions and enable TSO.

Better now. But it can be cleaner.

Oct 16 2024, 10:40 PM
cc added inline comments to D43470: tcp: refactor cwnd during SACK transmissions and enable TSO.
Oct 16 2024, 2:33 PM
cc added inline comments to D47130: tcp: remove the `goto drop` label by reusing equivalences in tcp_do_segment()..
Oct 16 2024, 12:31 PM
cc updated the diff for D47130: tcp: remove the `goto drop` label by reusing equivalences in tcp_do_segment()..

Add the __inline keyword to avoid overhead when possible.

Oct 16 2024, 12:27 PM

Oct 15 2024

cc added inline comments to D43470: tcp: refactor cwnd during SACK transmissions and enable TSO.
Oct 15 2024, 8:27 PM
cc requested review of D47130: tcp: remove the `goto drop` label by reusing equivalences in tcp_do_segment()..
Oct 15 2024, 5:07 PM
cc added a comment to D47106: add TH_AE capabilities to ppp and pf.

My current concern is that the definition and the usage of the super set macro TH_FLAGS or TCPF_ALL are inconsistent. For example, TH_ECE is in TH_FLAGS, but TH_ECN is in TCPF_ALL.

Oct 15 2024, 1:15 PM
cc added a comment to D30155: ixgbe: Bring back accounting for tx in AIM.

Ok this is a bit messy code and comment wise but I have the new algorithm working in what I believe to be the correct way with some bug fixes versus the origin and would like some data to see how to proceed before tidying everything up.
@cc it looks like emulab has ix(4) on d820s nodes, would you be willing to take a look at these 3 options similar to the e1000 test?

  • Default in HEAD/STABLE: sysctl dev.ix.<N>.enable_aim=0
  • New algorithm (on by default with this patch) sysctl dev.ix.<N>.enable_aim=1
  • Old algorithm (FreeBSD <10) sysctl dev.ix.<N>.enable_aim=2
Oct 15 2024, 11:41 AM

Oct 14 2024

cc added inline comments to D47106: add TH_AE capabilities to ppp and pf.
Oct 14 2024, 3:36 PM
cc accepted D47063: extend the use of the th_flags accessor function.
Oct 14 2024, 3:08 PM
cc requested changes to D47063: extend the use of the th_flags accessor function.

I current concern is that new code for the TH_AE shall be in a separate patch, so that this patch can be a pure big non-functional change.

Oct 14 2024, 1:02 PM

Oct 11 2024

cc added inline comments to D43470: tcp: refactor cwnd during SACK transmissions and enable TSO.
Oct 11 2024, 1:48 PM
cc requested changes to D43470: tcp: refactor cwnd during SACK transmissions and enable TSO.

Need code update.

Oct 11 2024, 12:46 PM
cc added a comment to D43470: tcp: refactor cwnd during SACK transmissions and enable TSO.

Because of commit 440f4ba18e3a, please re-base.

Oct 11 2024, 12:45 PM

Oct 10 2024

cc added a comment to D43355: tcp: fix erroneous transmission selection after RTO w/ SACK incoming.

By the way based on my test, I didn't find this statement In addition, cwnd used to be 1 MSS right after RTO, increasing to 2 MSS more recently. to be true in your SUMMARY section. Also Address this by setting up snd_recover just in cc_cong_signal. needs to be revised.

Oct 10 2024, 3:37 PM
cc accepted D43355: tcp: fix erroneous transmission selection after RTO w/ SACK incoming.

With the provided packetdrill scripts before/after the fix, my test result is in my wiki: testD43355.

Oct 10 2024, 3:19 PM

Oct 9 2024

cc added inline comments to D43355: tcp: fix erroneous transmission selection after RTO w/ SACK incoming.
Oct 9 2024, 10:33 PM
cc added inline comments to D43355: tcp: fix erroneous transmission selection after RTO w/ SACK incoming.
Oct 9 2024, 7:40 PM
cc accepted D46768: e1000: Re-add AIM.

I have no problem with this patch after testing it in Emulab. The test result is in my above comment.

Oct 9 2024, 3:56 PM
cc added a comment to D46768: e1000: Re-add AIM.

If I recall these machines are Pentium 4 era and pretty CPU constrained. You can try the tunable 'hw.em.unsupported_tso=1' and then enable TSO on the interface to get some more bulk bandwidth, they are stable with TSO.

Are you able to detect any improvements or regressions otherwise? ping-pong time at low packet rate between two systems both set with enable_aim=0,1,2 would be interesting.

Oct 9 2024, 1:34 PM

Oct 2 2024

cc added a comment to D46768: e1000: Re-add AIM.
In D46768#1069015, @cc wrote:

@cc this code works well in my testing. There are now some quality of life improvements, at runtime you can now switch in the middle of a test. I run a tmux session with three splits, one of systat -vmsat, one of the benchmark (iperf3 or whatever), and one to either toggle sysctl dev.{em,igb}.<interface number>.enable_aim=<N> where <N> description which follows. You can also do something like sysctl dev.igb.0 | grep _rate to see the current queue values.

Existing static 8000 int/s behavior (how the driver is in main):

sysctl dev.igb.0.enable_aim=0

Suggested new default, you will boot in this mode with this patch:

sysctl dev.igb.0.enable_aim=1

Low latency option of above algorithm (up to 70k ints/s):

sysctl dev.igb.0.enable_aim=2

ixl(4) algorithm bodged in that would need to be cleaned up:

sysctl dev.igb.0.enable_aim=3

I would be curious to know what you find with these different options in an array of testing and I will use the results to ready this for actual use.

I didn't find any rate change by the sysctl. Please let me know if the hardware does not support this new change.

root@s1:~ # sysctl dev.em.2.enable_aim=0
dev.em.2.enable_aim: 0 -> 0
root@s1:~ # sysctl dev.em.2 | grep _rate
dev.em.2.queue_rx_0.interrupt_rate: 20032
dev.em.2.queue_tx_0.interrupt_rate: 20032
root@s1:~ # sysctl dev.em.2.enable_aim=1
dev.em.2.enable_aim: 0 -> 1
root@s1:~ # sysctl dev.em.2 | grep _rate
dev.em.2.queue_rx_0.interrupt_rate: 20032
dev.em.2.queue_tx_0.interrupt_rate: 20032
root@s1:~ # sysctl dev.em.2.enable_aim=2
dev.em.2.enable_aim: 1 -> 2
root@s1:~ # sysctl dev.em.2 | grep _rate
dev.em.2.queue_rx_0.interrupt_rate: 20032
dev.em.2.queue_tx_0.interrupt_rate: 20032
root@s1:~ #

This looks to me like it is working, the algorithm is dynamic and 20k would be latency reducing idle queue. At enable_aim=0, you would see 8000. 20k looks right for an idle queue, what happens if you place a bulk load through it like iperf3? It should drop down to 4k.

Oct 2 2024, 8:34 PM
cc added a comment to D46824: tcp_output: Clear FIN if tcp_m_copym truncates output length.
In D46824#1068981, @jhb wrote:

I can fix the type mismatch during commit. I have not looked to see if other stacks are affected.

Fixing the type mismatch would be good. I think other stacks are not affected, since I think they
do not send a FIN before any outstanding data is ACKed and nothing is buffered anymore.

Oct 2 2024, 7:58 PM
cc added a comment to D46768: e1000: Re-add AIM.

@cc this code works well in my testing. There are now some quality of life improvements, at runtime you can now switch in the middle of a test. I run a tmux session with three splits, one of systat -vmsat, one of the benchmark (iperf3 or whatever), and one to either toggle sysctl dev.{em,igb}.<interface number>.enable_aim=<N> where <N> description which follows. You can also do something like sysctl dev.igb.0 | grep _rate to see the current queue values.

Existing static 8000 int/s behavior (how the driver is in main):

sysctl dev.igb.0.enable_aim=0

Suggested new default, you will boot in this mode with this patch:

sysctl dev.igb.0.enable_aim=1

Low latency option of above algorithm (up to 70k ints/s):

sysctl dev.igb.0.enable_aim=2

ixl(4) algorithm bodged in that would need to be cleaned up:

sysctl dev.igb.0.enable_aim=3

I would be curious to know what you find with these different options in an array of testing and I will use the results to ready this for actual use.

Oct 2 2024, 7:38 PM

Oct 1 2024

cc added a comment to D46824: tcp_output: Clear FIN if tcp_m_copym truncates output length.

I think this change also applies to the bbr and rack stacks.

Oct 1 2024, 2:03 PM
cc requested changes to D46824: tcp_output: Clear FIN if tcp_m_copym truncates output length.
Oct 1 2024, 1:57 PM
cc accepted D46850: tcp: small cleanup.

Looks good to me. Thanks for removing the goto label skip_alloc that improves reading.

Oct 1 2024, 1:42 PM

Sep 27 2024

cc accepted D46793: tcp: improve ref count handling when processing SYN.
In D46793#1067415, @cc wrote:

Does the summary section need to be updated? I didn't find the mentioned leaking part in code. Or am I missing something?

Sep 27 2024, 8:50 PM
cc added a comment to D46793: tcp: improve ref count handling when processing SYN.

Does the summary section need to be updated? I didn't find the mentioned leaking part in code. Or am I missing something?

Sep 27 2024, 6:55 PM
cc added a comment to D46768: e1000: Re-add AIM.

Rebase on main and some small improvements and bug fixes. Upon more testing the reimported algorithm is tuned for igb and less governed than intended on lem/em due to a different unit of measure on the ITR register. Need to think a little on how I would like to handle that.

Sep 27 2024, 1:31 PM

Sep 24 2024

cc added a comment to D46768: e1000: Re-add AIM.

Thanks for adding me as one of the reviewers. I will look at this patch and more likely test it in one of the machines in Emulab.

Sep 24 2024, 9:36 PM

Sep 17 2024

cc committed rGee4506105171: cc_cubic: use newreno to emulate AIMD in TCP-friendly region (authored by cc).
cc_cubic: use newreno to emulate AIMD in TCP-friendly region
Sep 17 2024, 2:38 PM
cc closed D46546: cc_cubic: use newreno to emulate AIMD in TCP-friendly region.
Sep 17 2024, 2:37 PM
cc updated the diff for D46546: cc_cubic: use newreno to emulate AIMD in TCP-friendly region.

re-base

Sep 17 2024, 2:08 PM