discussed this internally, but want to have external review before commit.

discussed this internally, but want to have external review before commit.

• syncing man page

• lint man

• sync man page entry

FWIW: I asked Liang Tian <l.tian.email@gmail.com> to verify in his special test scenario if this implementation of PRR performs as expected.

Can we have an updated netstat help and man page, for the new "-O" option, please?

• make maxseg u_int,
• fix tcpstat accounting for sack,
• remove redundant conditional check

• add dscp to man page, and keep equal sign between keywords
• output dscp of target only if configured

• improve man page grammar

Moved the setsockopt/getsockopt from socket level to IP_PROTO level (IPV6_PROTO, the numeric ids are identical), which addresses the concerns about the cold cacheline hit (inp->inp_flags2 should be hot in the ip_output path. Also, this change alignes slightly better with where the Ethernet PCP "lives" (as marking on ethernet packets, not internal unix sockets, which IMHO is more close to an IP packet ).

• move VLAN_PCP to INPCB, and move sockopt to IP_* / IPV6_* from SO_VLAN_PCP

So, how about moving the PCP to become part of the inpcb, and use IPPROTO sockopts instead. Sounds like that may be the better approach; doing this in the socket struct was "just" the easiest way to get a proof-of-concept running for various reasons... While the PCP is part of the (extended) Ethernet Header, there are no setsockopt Protos that deal with data on that level...

Turned out that this change is unnecessary, when SACK loss recovery works properly.

• update man page accordingly

• move cc-specific variables output to -C

• adjust column width to maximum string length

In D26518#590315, @tuexen wrote:

Not sure about showing the TCP stack name and the TCP congestion under the same flag. The TCP congestion control name scales to other transports, the TCP stack name doesn't.

Wouldn't the numbers fit also under -x?

• move stack name output to -c option

• address uppercase oversight in comment

In D26478#589561, @tuexen wrote:

Another question: what about RACK and BBR? Do they need a similar change?

• renaming macro to reduce collision risk

• adding statistics and validating approach
• cleaning up branch
• add "faster" path for majority of (bulk) transmissions

Packetdrill script to validate correct IW behavior. However, the 1 / 4 / 1 / 2 / 2 segment transmit sequence around the end of the loss recovery episode appears odd?

I'm ok with having the user interface heavy-lifting all done in ifconfig (and allowing a more simple kernel API, which doesn't strictly forbid "unusal" configurations.

In D26436#588650, @freebsd_oprs.eu wrote:

 Will (s)vlan1.44 and (s)vlan2.44 work?

This is an interesting point (assuming the question is about using the dot notation to create interface clones with ifconfig).

• ifconfig vlan1.44 create creates a 802.1Q stack (ETHERTYPE_VLAN over ETHERTYPE_VLAN).
• ifconfig svlan1.44 create creates a 802.1ad stack (ETHERTYPE_QINQ over ETHERTYPE_QINQ, not so useful in itself).

This is only logical (as per the vlan/svlan prefix rule), but admittedly it may seem deceptive to some users.
I would personally recommend against using the dot notation for stacked VLANs.

• remove redundant maxseg

Will there be an accompanying patch to tcpdump, to deal with stag / svlan headers - possibly of variable size - in the BPF code?

• use dynamic tcp_maxseg(tp) instead of t_maxseg in PRR calculations

• Update Diff to Head to apply cleanly

I wanted to suggest using -C (for reasons, instead of -c), but seeing this is already addressed...

In the man page, do we want to refer to RFC2474 and RFC3168, so that people are at least warned when the tos / tclass bytes are using not only the DSCP field, but also the ECN codepoints in ping / ping6 / traceroute / traceroute6?

• INP lock should be retained until socket wakeup calls are completed.

• shift TOS predefinitions and dscp field correctly around

• uclparse hex values for dscp too

• adding uclparse and using temporary dscp variable when doing setsockopt

• prevent the ECN bits to be set.

Looks good - t_bytes_acked is already a "corrected" value to deal with ACK duplication / ACK splitting; During CA, cwnd should grow by 1 MSS every window, and accounting when a window was transferred is t_bytes_acked.

This Diff has morphed over time quite dramatically; Originally only intended to fix one socket upcall at an inopportune time (using a hack that simply prevented the transmission of a premature ACK), it was suggested to revamp all socket upcalls throughout the stack.

• straighten comment further

• always use absolute cubic_cwnd value
• update cubic cwnd comment to reflect new logic