In D4295#1077477, @gallatin wrote:

Why is this re-surfacing?

I think the ratelimit code has a better solution, since TCP can query how full the nic queue is and avoid ENOBUFs entirely by avoiding sending on a full queue. The problem with doing this in general is that, outside of ratelimit, the TCP stack has no way to determine what NIC queue a packet will be sent on.

Why is this re-surfacing?

In D25681#568379, @lutz_donnerhacke.de wrote:

In D25681#568368, @eugen_grosbein.net wrote:

ce(4) for PCI G.703/E1 card,
cp(4) for PCI V.35/RS-232/RS-530/RS-449/X.21/G.703/E1/E3/T3/STS-1 cards,
and cx(4)/ctau(4) for some ISA cards but these do not exist in FreeBSD 13 anymore,
removed by emaste@ recently.

Both ce(4) and cp(4) are i386-only drivers at present.

Such synchronous lines are still in use (here):

• G.703 is common in phone systems.
• X.21 for leased lines (with old contracts),
• E1/E3 for SDH (carrier grade) leases lines.
• RS-232 is the ordinary serial port, the other RS- are industry specific serials (mainly other voltages)

But you are right: Do we really need a specialized PPP hardware support these days?
Do we really want to run a recent kernel on this antique hardware? It would be a sacrilege.

Normal PPP over serial lines (currently available) does work using ppp(4)

In D25681#568368, @eugen_grosbein.net wrote:

ce(4) for PCI G.703/E1 card,
cp(4) for PCI V.35/RS-232/RS-530/RS-449/X.21/G.703/E1/E3/T3/STS-1 cards,
and cx(4)/ctau(4) for some ISA cards but these do not exist in FreeBSD 13 anymore,
removed by emaste@ recently.

Both ce(4) and cp(4) are i386-only drivers at present.

Sorry for the mess, my latest actions on this differential were unintentional, some problems with old Firefox.

CCing Roman Kurakin (ce(4)) and Serge Vakulenko (cp(4)), see later.

In case anybody is wondering, the source of the commit is here: https://freshbsd.org/commit/netbsd/src/hRr2tvIj1vj7QI2C

Good catch on the tidbits, here's an revised patch.

This looks ok to me modulo the nits I pointed out.

Made the corrections.

Lawrence reviewed this during IETF104, Michael volunteered to follup up with the full commit process.

• prepare to land

Over the last two or three weeks, we have run a large number of performance regression tests including this patch, in particular again workloads with frequent app-stalls (no additional data to send for about an RTO interval). That type of workload very often causes burst to be transmitted, including self-inflicted packet drops.

Looks good. I think Richard can update more that we recently tested this patch.

Looking at D8225, that all seems to be code while in loss recovery. This patch is to restore a sane minimum cwnd once exiting loss recovery - so I don't see how these would be directly related.

I remember we tried to analyze and improve this and found some unintended consequences between @hiren and @lstewart https://reviews.freebsd.org/D8225 so it got backed out. @lstewart do you remember the details for backing it out?

• fixing trailing whitespaces

• remove siftr patch

• fixing trailing whitespaces

Here is the output of the now functional siftr, without and with the patch;

In D17614#402480, @chengc_netapp.com wrote:

I have been testing this patch against a stable/11 build. Over a 1Gb/s link with emulated 40ms RTT and (10^-4) loss rate, I use iperf from a FreeBSD node to send traffic to a 4.15.0-39-generic Ubuntu16.04 client.

[...]

Using siftr, I still see the single MSS cwnd, and sometimes with a 40ms delay to update a second cwnd. The full cwnd log is attached.

cwnd_33710.txt106 KBDownload

The congestion control in use is newreno.

timestamp cwnd ssthresh
...
1.92838096618652 115052 70875
1.92838382720947 1448 56940 <<< single MSS
1.96786689758301 2896 56940 <<< 40ms delay
1.96786999702454 4344 56940
1.96787786483765 5792 56940
1.96788096427917 7240 56940

I have been testing this patch against a stable/11 build. Over a 1Gb/s link with emulated 40ms RTT and (10^-4) loss rate, I use iperf from a FreeBSD node to send traffic to a 4.15.0-39-generic Ubuntu16.04 client.

Attached is a tcptrace of a real-world observed issue, where the lack of RFC6582 results in cwnd shrinking down to 1 MSS, followed by delayed ACK timeout and congestion avoidance growth of cwnd (1 MSS per RTT).

Thanks for the review request.
I will test this patch in Emulab.net before I give more feedback.

This packetdrill script should complete without error, when IW10 and the above patch are applied, for a SACK session, or non-SACK session.

Minor comment edit
and moving to GIT/Phabricator/ARC workflow

This LGTM taking @hiren suggestion to drop the unused TCPTV_CPU_VAR define. At LLNW we ran w/o delack to work around most of the issues this addresses in a more elegant way.

@lstewart ping

We needed to refine this further at ISLN.

@lstewart is this worth updating or should I just abandon?

I'll grab this and shovel it in after builds are done.

Fix comment per rstone and jegg

I've written some unit tests that covering these cases here:

Noob question, should freebsdversion bump since this alters the ABI?

Use the libxo plurals and fix the pmtud-failed label

Looks good (with one minor nit inline).