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.