I think you are not only renaming variables, but also adding new ones. Please reflect that in the commit message.

Be consistent.

Address most of cc's comments.

There is the plan to move the base stack away from ticks and use usecs everywhere. But we wanted not to do this before stable/14 is branched.

You might want to wait also for Richards' approval, since he is much more familiar with the code than I am.

Changing the algorithm is one thing I agree with. But why change the output in the summary from IP addresses / port numbers to flow IDs? For me the IP addresses and port numbers are easier to read and more helpful.

In D39860#907451, @netchild wrote:

Should the man-page tcp_rack(4) be changed at the same time to mention TCP_BLACKBOX as an optional dependency (and what feature it unlocks in rack)?

In D39835#906912, @cc wrote:

In D39835#906901, @cc wrote:

In D39835#906803, @tuexen wrote:

In D39835#906795, @cc wrote:

In D39835#906794, @tuexen wrote:

What do we gain from removing this feature? My understanding is that if it is not enabled, it does not have a substantial CPU overhead. I have no idea who uses siftr and if they use this feature...

This feature is not used AFAIK. We have less carbon print (at least 10 chars of "0x00000000") per record after removing this feature.

OK, so I understand that it makes sense not to print it, if the feature is not used. But I have (in general) a hard time to tell, which features are used and which are not... So how do you know that you are not removing a feature considered important by some people?
An argument I see in favor of this change is that I'm not aware of any tool reading a .pcap file and computing the hashes for the packets.

Let's assume this is a dead feature, or the original authors do not need it any longer. Also, a hash value is hard to use for a packet identification. I will consider tcp.seq, tcp.ack, and tcp.len in the tcphdr for such identification. Besides, the inconsistency between IPv4 and IPv6 for this feature does not make sense.

On a second thought, if there is really someone who uses this feature. That also means this user knows how/where to add this missing code to study TCP, under the BSD license.

In D39835#906795, @cc wrote:

In D39835#906794, @tuexen wrote:

What do we gain from removing this feature? My understanding is that if it is not enabled, it does not have a substantial CPU overhead. I have no idea who uses siftr and if they use this feature...

This feature is not used AFAIK. We have less carbon print (at least 10 chars of "0x00000000") per record after removing this feature.

What do we gain from removing this feature? My understanding is that if it is not enabled, it does not have a substantial CPU overhead. I have no idea who uses siftr and if they use this feature...

Isn't that another backwards incompatible change?

Update to latest version of the main tree.

In D39591#901811, @glebius wrote:

I like the combing of all these functions prologue.

I have one note, though. The "PRU" in the commit message made me notice that tcp_bblog_pru() again started to use this PRU_XXX namespace. If you started using it again, it needs to get out of in_kdtrace.h. But I'd rather suggest to create some own namespace for BB logging and forget this legacy. The long story of PRU_XXX namespace can be found in a comment in in_kdtrace.h.

Provide context in patch file.

Add changes to the man page.

Would be nice to know what the problem is you are experiencing with the DSCP for IPv6.

In D39516#899644, @zarychtam_plan-b.pwste.edu.pl wrote:

Thanks for taking care of the problem. Will it grow vnet memory requirements? Can the change be applied safely to stable/13? Are any plans to MFC when gets committed to HEAD ?

The diff looks good.