Thanks for the effort of writing an initial man page. I wanted to do this for a long time...

The Linux socket option also bound the time user data remains un-transmitted. I guess this is not handled by the FreeBSD one.

I think arbitrary unrelated constants should not be put into a single enum.

I did a stress test on my ten64 and it is now sending traffic without any problems.

In D55915#1279706, @jhb wrote:

I think rather than trying to overload -B, it would be better to just use a different getopt() letter for this mode. I would suggest using -R for reading from a BAR but keep 'D' as an alias for backwards compatibility, and using -W for writing into a BAR.

In D55534#1271706, @timo.voelker_fh-muenster.de wrote:

In D55534#1270843, @tuexen wrote:

Does this patch solve any problem?

Yes. I tried to dump the content of a PCI BAR with:

pciconf -D pci0:0:10:0 0x18 | hexdump

This command failed with EINVAL. It calls pci_bar_mmap(pcidev, pbm) in sys/dev/pci/pci_user.c, which returns EINVAL if pmap_is_valid_memattr(pmap, mode) returns false. With this patch, I was able to dump the content of the PCI BAR.

Does this patch solve any problem?

Address comment raised by glebius.

Use names for members in struct tcpcb as suggested by glebius.

Committed in 8d2f910ceb0f.

In D55460#1269594, @rrs wrote:

include close-wait

In D55460#1269353, @rrs wrote:

In D55460#1269209, @tuexen wrote:

In D55460#1269031, @rrs wrote:

The reason I am suggesting to include FIN WAIT 1/2 is that we stopped sending, but the
peer can send us data for an unlimited amount of time.. Shouldn't this data transfer towards
us be able to use ECN? That would mean we should send ACKs based on the received ECN markings.
Am I wrong with this? Why shouldn't half closed TCP connections not use ECN for the
direction data is still sent?

Hmm FIN WAIT 2, yes I can see that since at that point you have transitioned to fully closed. And yes
the peer could keep in established on its side a long time.. But are you not in the middle of your close
in FIN WAIT 1?

Have a look at state diagram.
When you close your writing end, you send a FIN and enter FIN WAIT 1. When you receive the ACK for this FIN, you enter FIN WAIT 2. From the perspective of your peer, there is no difference if you are in FIN WAIT 1 or FIN WAIT 2 (or ESTABLISHED). The peer can send data. As long as it can send data, ECN should be usable, I think.

I will update the review.. however I have trepidation on this whole issue. You have two ack-regimes going on.

1. TCP's normal acking -- delayed ack or ack every packet
2. ECN commanding acks.

Now the interaction of the two regimes could prove interesting with un-anticipated consequences. Especially in
state machine transitions. So though yes, FIN WAIT 1/2 probably should be included in the exception list, I just
feel we could have issues down the road.. not sure what, but just the interactions of these algorithms could
be a src of problems... In ESTABLISHED I see no problem worse that happens is you end up acking every packet.
But in any other state I wonder...

I will increase your exclusions.. but I am concerned...

In D55460#1269031, @rrs wrote:

The reason I am suggesting to include FIN WAIT 1/2 is that we stopped sending, but the
peer can send us data for an unlimited amount of time.. Shouldn't this data transfer towards
us be able to use ECN? That would mean we should send ACKs based on the received ECN markings.
Am I wrong with this? Why shouldn't half closed TCP connections not use ECN for the
direction data is still sent?

Hmm FIN WAIT 2, yes I can see that since at that point you have transitioned to fully closed. And yes
the peer could keep in established on its side a long time.. But are you not in the middle of your close
in FIN WAIT 1?

In D55460#1268987, @rrs wrote:

In D55460#1268967, @tuexen wrote:

In D55460#1268958, @rscheff wrote:

LGTM

I think CLOSE WAIT should be replaced by FIN WAIT 1 and FIN WAIT 2. My mistake.

Actually no. I don't think so. The idea here is the main stack *not* ecn should be controlling what
acks are sent when we are closing. In FIN WAIT1/2 we are doing the 4-way handshake dance and
ECN (and any CC behind it) needs to not be involved with it. The stack in theory should still
react the correct way and go through the proper handshake sending acks finacks and anything
else it needs. We just don't want ECN toggling in TH_ACKNOW in the middle since it is
unaware of the 4 way shutdown taking place..

In D55460#1268958, @rscheff wrote:

LGTM

In D55460#1268552, @rrs wrote:

In D55460#1268502, @tuexen wrote:

What is with BBR?

Hmm well for BBR its a non-issue since BBRv1 does *not* support ECN. And yes thinking on it

OK.

being in CLOSE_WAIT should still allow ack's to go out. I will change that...

In D55460#1268933, @rrs wrote:

Ok I have added the CLOSE_WAIT stage Michael suggested. However I am not
sure that is a wise thing. It may mean an extra ack in the closing state i.e. while you
are waiting for your user to close.. but on the other hand that may take a *very* long
time.. so I am ambivalent about it

I added a script which show the behavior before the patch. I also cleaned up the formatting of the script showing the behavior after the script.

What is with BBR?

In D55454#1268359, @bms wrote:

Any plans to add gencnt to SCTP sockets?

Olivier Van Acker did a GenAI lemming run with Cursor last week to auto-generate sctpsso(8) from tcpsso(8) as a template.

Whilst it generated an (at first) viable looking code artefact that compiled without error against FreeBSD 15.0-RELEASE, the AI model concerned had hallucinated the existence of two major things: gencnt existing for SCTP sockets, and a *.sockopt sysctl for SCTP to actually set the options.

In D55410#1267939, @timo.voelker_fh-muenster.de wrote:

I agree on @pouria's comment.

A __predict_false makes sense in the IPv6 case as well.

With context.

Rebase and cleanup.

Minor cleanup.

Update names of structure and provide a way that setsocktion SO_LINGER is not required anymore.

Improve inputs validation for UDP encapsulated TCP segments.

Fix checksum computation.

Fix TCP over UDP tunneling.

In D34139#1266200, @bms wrote:

TCP_NODELAY is missing from the man page (15.0p3).

Fix sender side stats counter and teach netstat how to print the stats counters added in this patch.

Allow socket option processing on inps with the INP_DROPPED flag set only for getsockopt() of the IPPROTO_TCP-level socket option with name TCP_RST_REASON_CODE, as glebius suggested.