re-base after commit b6c137de0af1

update function names based on Michael's suggestion

split this patch into two parts: this patch and D46546

re-base

Besides, I am wondering if TCPSTAT_INC(tcps_sndacks) and TCPSTAT_INC(tcps_sndtotal) consistency can also be improved after successful syncache_respond().

Your summary section claims "In addition, cwnd used to be 1 MSS right after RTO, increasing to 2 MSS more recently." But I could not find the code change where cwnd is changed to 2MSS after RTO. Please elaborate if the summary needs to be revised or I am missing the point.

Are you planning to remove the corresponding code in kernel space in a separate patch?

reference in SYSCTL(9)

Thought for a while if these new lines can be wrapped into a new function like try_cc_attach_from_listener(), but it looks to be unnecessary.

In D46141#1052243, @peter.lei_ieee.org wrote:

LGTM.
I think for those who want newly accepted connections to use a "new" default stack, there is a mechanism using tcpsso that could be used to (attempt to) change the listening socket's stack so that new connections use that stack. This would need to be run for all desired listening sockets though.

This change seems to revert the commit 6134aabe38c8. Is there any behavior change on V_functions_inherit_listen_socket_stack == 0 after this change? Is the TCP function block from the listener changed dynamically once the default stack is changed?

ship after update

Looks good to me, after the comment update for struct cc_var.

In D46066#1051183, @tuexen wrote:

In D46066#1050919, @cc wrote:

Just saw https://reviews.freebsd.org/D46068. If this patch has not been committed, we can still further revise it, so that D46068 can be cleaner on function re-use.

I think the logic here can be split into two functions, such that the refined logic 1 on checking if we should send ACK can be re-used across multiple places.

logic 1:

bool
is_ack_unlimited(struct tcpcb *tp)
{
    /* focus on checking the epoch and
     * if should send ACK, return true; else return false
     */ 
}

logic 2:

void
tcp_send_challenge_ack(struct tcpcb *tp, struct tcphdr *th, struct mbuf *m)
{
    if (is_ack_unlimited(tp)) {.
       tcp_respond();
    ....
    }
}

I don't get the point. Eventually, all places should use tcp_send_challenge_ack(), I think. But that is multiple commits away.

Just saw https://reviews.freebsd.org/D46068. If this patch has not been committed, we can still further revise it, so that D46068 can be cleaner on function re-use.

code clean up

Thanks for the update. Looks better and just a small concern about TCP_MAXWIN for 65535.

After reading the paper and IETF slides, it looks good to me on top of the general view. Just some small concerns below.

Thanks for the update! Looks good to me.

Over all looks good to me. Thanks for the update.

I started to draft the results into wiki pages from testing this patch. Please let me know any metrics you would like to see.

Other than the comment wording like "rtwn supports the default set of net80211 supported ciphers (IEEE80211_CRYPTO_[WEP, TKIP, AES_CCM])", looks good to me.

Looks good to me. :)

Start to pick up slowly about where I left, and touch the water. :)

I see you made comments of "ieee80211_set_software_ciphers() is not needed" in if_rtwn.c. Do you mind to add it in the rest of the drivers files? Or is there any better/central place to put such comment or document it?

update based on bz@ comments

rebase before scrutiny check

Individual accept.

Just some minor issues.

If you have a plan to figure out TEXT_SET(crypto##_set, name##_modevent) and TEXT_SET(ratectl##_set, alg##_modevent), I have no problem with this patch.

Cautious individual accept.

I don't get it why this change made a difference in your test. Is it because of the bug I pointed in TEXT_SET ?

LGTM

The rest looks good to me.

In D44827#1023217, @adrian wrote:

In D44827#1023209, @bz wrote:

In D44827#1023208, @adrian wrote:

eg ath(4) would do something like:

How do you want to implement ath_settkipmic() "nicely" without exposing the field?

oops my bad. it'll be a flag for hardware encryption support! I fixed the code snippet.

Also do you have any plan to update the man page regarding the new field ic_sw_cryptocaps besides ic_cryptocaps ?

Also please update the Summary section in this review, i.e. the mentioned new field ic_wpa_cryptocaps is actually the ic_sw_cryptocaps in the code change.

LGTM

I am intending to give approval, but I am afraid of missing the new response to my review comment for the code comment update. So let's be patient. :)

In D43966#1023788, @bz wrote:

@cc Adding LOCK asserts is a very good idea; not all the functions need them if I remember correctly. Should I really add it to this "fix" or should I do a separate full pass on the linux_80211_macops.c file?

In D44463#1014016, @adrian wrote:

you negotiate it as an extension, and then it's used to switch STA keys without dropping frames.

During association with the AP, sw/hw keys (indexes) are set. And before tx, the hw key is selected by sw key's index returned from ieee80211_crypto_get_txkey(), same way as without LKPI_80211_HW_CRYPTO.