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

• Merge branch 'master'

• Merge branch 'master'

fix spelling in man page

@rrs - I believe you wanted to comment if the current layout of the relocated socket upcalls looks ok for the RACK stack.

It's been 6 weeks now (5 weeks after the suggested "speak up now" deadline), still require a transport sign-off, before committing...

Good catch! The fix looks perfect

• update comment to correctly describe conditionals

What happens if tcpcb and inpcb are released without making sure the write lock is released? (This seems a follow up on D25583 , correct?) IIRC, if tcp_newtcpcb() returns NULL, the associated inpcb would be freed in the calling function - but would that mean that the write lock held in some data structure would still linger (and leak memory)?

Looking at all the capability flags, I really wonder if one couldn't save some flag-bits by consolidating some of the seperated-out v4 and v6 flags into codepoints; I would assume that hardware supporting e.g. TSO6 but not TSO4 is quite uncommon (as with CSUM, TLS and WOL support), and some of those flags could be consolidated into codepoints (enum) rather than individual bits - if subsequently there is a dire need to conserve flag bits. IMHO bikeshedding around running low on flag bits in this diff is not strictly necessary.

• only update style and comment. logic was ok before.

Re-inspecting the suggested fix. The concave region is where cubic_wnd < cwnd_max, and the convex region is cubic_cwnd > cwnd_max.

• record going out from slowstart at the earliest possible moment

• calc ticks_since_cong properly

This mechanical change looks good to me. Just wondering is similar missing sbunlock would be in RACK or elsewhere in BBR. (but didn't spot anything obvious just now)

• simplify patch and use snd_cwnd_prev in cc_cubic only.

• add comment to explain the semantic change to sack_changed

This improvement of the SACK scoreboard accounting is actually what Jason seems to have asked for in D3971 when the RFC6675 pipe calculation was added.

• style fix

Should this

• If the destination address is INADDR_ANY,
• use the primary local address.

be documented in a man page in addition to the comment in the code?

Using the upstream variant of bbr (not "bbr_latest"), I could not recreate the reported issue (that is, the packetdrill script failing) with either bbr or the base stack...

• Merge branch 'master'
• whitespace fix in comment

• remove flag field microoptimization

• remove flag field microoptimization

• update flags to uppercase and expand constant to 32 bit.