Can you please describe the actual reported problem?
Thanks!

Already fixed by some other commit.

Haven't been able to actually test this out yet but don't want to holdup the commit for that.

1. look at existing comment about CTD.
2. Add an example config entry in to the EXAMPLES section of the manpage.

This will be quite useful! Thanks.

tcp(4) manpage needs to be updated.

Thanks a lot for the usage writeup. And yep, I do understand that we need to get this in so RACK/BBR can follow. Good that this can be used with default stack so there is some way to test/use this functionality before RACK/BBR comes in.

Thanks for this work!
I can see some good comments in the code but if there is a general design doc or excerpt on pacer, it'd be nice to add that in the beginning of tcp_hpts.c

I don't have time to look at this the way I intended. :-)
Removing myself as a reviewer/blocker so others can decide.

In D14141#299284, @jason_eggnet.com wrote:

In D14141#299283, @hiren wrote:

@jason_eggnet.com why did you move K calculation from post recovery to ack received? I don't think that's correct.

So basically, why not delay the calculation of K until right before it is needed. Use the previous value of K if neither of the inputs have changed.

@jason_eggnet.com why did you move K calculation from post recovery to ack received? I don't think that's correct.

BTW, I am okay with this bandaid fix for now.

In D14141#297953, @jason_eggnet.com wrote:

In D14141#297944, @hiren wrote:

I remember this one. :-)
jegg, can you please elaborate on 'cwnd < 1smss bad for other parts of the code' part?
Thanks.

A zero cwnd can cause infinite looping (i.e., continual goto again; looping) within tcp_output(). Technically even one byte would be ok but there's no real point to having the cwnd be some fractional mss value.

In general the concept of having a zero cwnd doesn't make any sense.

I remember this one. :-)
jegg, can you please elaborate on 'cwnd < 1smss bad for other parts of the code' part?
Thanks.

People wanting to disable tfo (for whatever reasons) may have different opinions but looks good to me on a quick glance. Thanks.

In D13718#287464, @pkelsey wrote:

In D13718#287006, @hiren wrote:

Awesome! Thank you for this work!

Now, sorry to be a PITA but you should separate out this into 3 reviews: 1) fast-open ON by default removing TCP_RFC7413 2) Bug fix for the issue in tcp_fastopen_check_cookie() 3) Client side TFO implementation.

I can do this I suppose, although I have to say it's hard for me to see the value in doing it as (2) and (3) seem pretty easy to evaluate in the current patchset, as (2) consists of moving a lock acquisition earlier in a small function and ensuring release on all the exit paths, and (3) is the mechanical removal of #ifdefs and the related rename of a kernel option that is used in one place. Perhaps because I don't think I fully understand the practical motivation for this separation, I'm also not sure whether or not it matters how I synthesize the new versions of the code - should they all be independent diffs against -current (which seems weird as it can hide interactions between the changes from review), or is there some preferred sequence (should the locking bug be presented as happening before or after all the other changes to same function)?

Awesome! Thank you for this work!

In D12639#264162, @emaste wrote:

The benchmarks we do have so far show a rather small regression

I know this has been in prod for quite some time and works. I don't want to engage in "best-practices" for this. :-) LGTM.

I am not too sure on details but can this be done with PCBGROUPS/RSS? https://github.com/erikarn/freebsd-rss/ has some examples.

It'd be nice to have a bit of a writeup on what hystart is and how its implemented here.

Do mention stable/10 rev also in your commit.

Thanks for the explanation. Change looks correct to me just that the code is a bit muddied with this single check moving elsewhere (for the right reasons) and a bit more code duplication in alt stack code. But I think those are out of the scope of this patch.

@bryanv do you have time to look at this now?

In D10424#216131, @tuexen wrote:

I observed the bug by using a SYN-ACK without any options. The retransmitted SYN does not contain the SACK option anymore. So it wasn't retransmitted.

For my understanding, what is the side-effect of this 'partial processing' before we eventually drop it? (I assume we do drop it but later in the path, right?)
Not against the patch but trying to understand what is driving this fix. :-)

Very nice work! Thank you.

Other than it not being able to build, I like the var name change requested by Robert and the general approach.

In D9365#194220, @ae wrote:

I'm curious, you plan to add this code into FreeBSD base tree, not into the contrib section. Do we need to have all these #ifdefs in such case? I doubt that we have all such HAVE_XXX macros defined in our environment. Also we already have removed AppleTalk support from the tree.

I'd appreciate another pair of eyes on this.

Can't actually review as an author of the patch. It'd be nice if someone else can look at it.

bump.
Is this still the most updated patch of this work?

In D9035#186666, @gnn wrote:

I could make an uglier macro. If that would please the audience.

Is it possible to handle 'm' being null in TCP_PROBE3() instead of these if/else checks everywhere?

Hi Michael, Is this ready to land in -HEAD?

In D8737#181056, @bz wrote:

Seems like this is a more conservative solution to avoid possible offload problems.

There's a couple of other things the came to my mind or I spotted in that code but for the sake of "just fixing" this looks right.

Right. This is fixing the *obvious* bug. Please let me know what else you have in mind and that way its logged for myself of someone else to pick up.

In D8737#180982, @kevin.bowling_kev009.com wrote:

[skip]

@kmacy suspects there might be drivers/firmware that cannot handle this but we haven't gone and dug any examples of that up. If that is the case, we should disable TSO on any packet with IP options set as the current code does, but additionally check for a flag on the output interface indicating that incompatibility.

Thanks for this fix. Nice catch.

• If we find a matching syncache entry, but there is a problem with validating it (e.g. RST, etc.), ignore it.

Hum, can you please provide an example of this? what could 3rd maching ack bring that doesn't validate? I am probably missing something obvious.

In D8552#177689, @jtl wrote:

Hiren,

Thanks for finding this bug and proposing a solution! Your solution looks fine in the sense that it mimics the rest of the behavior of this function when validation fails.

However, I think this function (and tcp_input(), which calls it) actually do the wrong thing. I believe the correct behavior should be:

• If we have a matching and valid syncache entry, setup the connection.
• If we do not find a matching connection, send a RST.

Also restore pre-r307901 behavior of alighning ssthresh on MSS boundary.

This is a bug exposed by recent commit https://svnweb.freebsd.org/base?view=revision&revision=307901

Talked to @rstone about adding some comments to make code more readable.

I tried running a few loss scenarios with various available CC algos and nothing seem broken. Loss scenarios include : dropping a single packet, dropping a bunch of packets, dropping a lot of packets to create severe loss situation, ack loss, etc.

Changing snd_cwnd tracking variable's name from win to cwin and its type to uint32_t.
I'll run all my tests tomorrow and update here with results.

@kmacy Can you please looks at my comments? I like the changes otherwise.

Ping!