In D45253#1035534, @tuexen wrote:In D45253#1035494, @lstewart wrote:Might be worth adding a check in tcp_subr.c:register_tcp_functions_as_names() that the handoff_ok hook is not NULL and return an errno + fail to register the module if it is?
This is already part of the diff, I think. See tcp_subr.c:1186. tcp_subr.c:register_tcp_functions_as_names() would return EINVAL like in the case where some other mandatory function is not provided.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Tue, Jun 4
Tue, Jun 4
Fri, May 31
Fri, May 31
Tue, May 28
Tue, May 28
In D45253#1035180, @tuexen wrote:In D45253#1035179, @lstewart wrote:Right now, the absence of the function means that it is not OK to switch, except the state is TCPS_CLOSED. So I think keeping the semantic of the absence of the tfb_tcp_handoff_ok() is in tune with POLA for all states except TCPS_CLOSED. The other reason is that one could use tfb_tcp_handoff_ok() as the first step of the switch. In particular, one could call something like tcp_timer_stop_nounlock as the last step of tfb_tcp_handoff_ok(). This does not work, if the semantic of the absence of tfb_tcp_handoff_ok() is that it is OK to switch.
Your comments are entirely reasonable so I don't have a strong objection against what you've proposed (although the idea of mutating the connection state/set up in handoff_ok() seems sketchy at best, but we can't stop anyone from doing it either).
I think the protocol would require that if tfb_tcp_handoff_ok() returns no error, tfb_tcp_fb_init() must be called. So you can put something in tfb_tcp_handoff_ok(), which either fails and does not change the state or succeeds and potentially change the state in a way that tfb_tcp_fb_init() expects. But this is up to the user of the API and we cannot control what is done the in callbacks.
Mon, May 27
Mon, May 27
Right now, the absence of the function means that it is not OK to switch, except the state is TCPS_CLOSED. So I think keeping the semantic of the absence of the tfb_tcp_handoff_ok() is in tune with POLA for all states except TCPS_CLOSED. The other reason is that one could use tfb_tcp_handoff_ok() as the first step of the switch. In particular, one could call something like tcp_timer_stop_nounlock as the last step of tfb_tcp_handoff_ok(). This does not work, if the semantic of the absence of tfb_tcp_handoff_ok() is that it is OK to switch.
Mon, May 20
Mon, May 20
Nit: why require tfb_tcp_handoff_ok() be implemented by a stack rather than treat the absence of the hook's implementation to be an implicit ok? Many of the hook functions are optional so it seems a bit unexpected to require that this hook function be implemented.
Apr 3 2024
Apr 3 2024
lstewart committed rG7eb92c502eb5: Reinstate returning EOVERFLOW from stats_v1_blob_clone() (authored by lstewart).
Reinstate returning EOVERFLOW from stats_v1_blob_clone()
Apr 2 2024
Apr 2 2024
lstewart committed rG743d4b7cc5e2: Fix the logic which determines if the destination Q variable can represent the… (authored by lstewart).
Fix the logic which determines if the destination Q variable can represent the…
lstewart added a reviewer for D44585: Reinstate returning EOVERFLOW from stats_v1_blob_clone(): markj.
Mar 2 2024
Mar 2 2024
Hi Mark,
Mar 2 2022
Mar 2 2022
lstewart added inline comments to D30036: Update Rack and BBR to the latest from NF fixing LRO issues along the way..
Dec 1 2021
Dec 1 2021
I won't have the time to review this in the near future but would note that many of the things I flagged for the original newreno hystart++ implementation also apply to this implementation. However, I wouldn't call any of them blockers so don't have an objection to you committing this at your discretion.
Nov 24 2021
Nov 24 2021
Nov 16 2021
Nov 16 2021
The whole point of this was that there were absolutely no logs what so ever when tcp_respond() was used. So prior to this set of commits you *never* saw anything when we responded to a packet (and that happens in many places in all stacks). Now I would have to study when we use tcp_respond() with a INP_RLOCK() this is a very narrow case I would imagine, but if you are not willing to get a INP_WLOCK() that implies to me you are not changing the TCB... but thats what logging does.
Nov 15 2021
Nov 15 2021
Nov 4 2021
Nov 4 2021
Thanks for fixing!
Nov 3 2021
Nov 3 2021
First pass feedback
Oct 22 2021
Oct 22 2021
I haven't finished reviewing yet but some initial thoughts in addition to my inline comments:
- Nit: please submit diffs with full context as it makes reviewing easier
- You need to address how enabling Hystart++ when using cc_newreno with the default FreeBSD stack will work
- The implementation pessimises the common case where newreno will be used without ABE or Hystart++ which is probably undesirable. The module's lack of a cb_init() hook implementation was very deliberate to avoid such pessimisation and also as noted inline, assumptions are made elsewhere that cc_newreno can always be used as an algo of last resort so we cannot allow init to ever fail.
Apr 5 2021
Apr 5 2021
Apr 2 2021
Apr 2 2021
lstewart committed rG9141b58b50a8: stats(3): Improve t-digest merging of samples which result in mu adjustment… (authored by lstewart).
stats(3): Improve t-digest merging of samples which result in mu adjustment…
lstewart committed rG1eb402e47af3: stats(3): Improve t-digest merging of samples which result in mu adjustment… (authored by lstewart).
stats(3): Improve t-digest merging of samples which result in mu adjustment…
Mar 25 2021
Mar 25 2021
lstewart committed rG2a878f01f22f: random(9): Restore historical [0,2^31-1] output range and related man… (authored by lstewart).
random(9): Restore historical [0,2^31-1] output range and related man…
lstewart committed rG828e6b5f5e30: random(9): Restore historical [0,2^31-1] output range and related man… (authored by lstewart).
random(9): Restore historical [0,2^31-1] output range and related man…
Mar 24 2021
Mar 24 2021
lstewart committed rGdbbf3e3f37d6: random(9): Restore historical [0,2^31-1] output range and related man (authored by lstewart).
random(9): Restore historical [0,2^31-1] output range and related man
Mar 23 2021
Mar 23 2021
lstewart accepted D29385: Make random() behaves as documented: "result is uniform in [0, 2^31 - 1]".
Loic doesn't have a commit bit, so I've offered to commit on his behalf.
Dec 13 2020
Dec 13 2020
lstewart committed R9:58d7bd1515b4: Document the __FreeBSD_version bump to 800061 in relation to the (authored by lstewart).
Document the __FreeBSD_version bump to 800061 in relation to the
lstewart committed R9:3079451f59fd: Add myself as requested by the committers-guide (authored by lstewart).
Add myself as requested by the committers-guide
lstewart committed R9:69079175b7cd: Add myself as requested by the committers-guide (authored by lstewart).
Add myself as requested by the committers-guide
Nov 24 2020
Nov 24 2020
lstewart added a comment to D26807: move cwnd and ssthresh updates into individual congestion control module.
In D26807#610464, @rscheff wrote:In D26807#610449, @lstewart wrote:In D26807#604494, @rscheff wrote:incrementing by t_maxseg (w/o TSopt) vs. tcp_maxseg() (w/ TSopt/MPTCP) does not lead to a unexpected transmission of 2 segments, when only a single segment would be expected (tcp_output prefers to send full segments but considers option overhead).
Incrementing by tcp_maxseg() is sightly less aggressive during CA, not?
First up, it seems buggy to me that the sender side accounts for received SACK blocks in the "effective" MSS computed by tcp_maxseg() for outbound segments. (Not your bug, but your change amplifies the effect of the bug).
Not quite sure I get your point here; are you saying the tcp_maxseg() is erraneously including received SACK blocks fom the previous ACK? Maybe you can send an annotated code snippet per direct mail?
Nov 23 2020
Nov 23 2020
lstewart added a comment to D26807: move cwnd and ssthresh updates into individual congestion control module.
Apologies for the delayed reaction...
benchmarks/spp: Update v0.4 -> v0.4.2
Sorry for the tardy comments, but a few things in this changeset caught my eye during our internal Netflix upstream merge review.
Nov 4 2020
Nov 4 2020
lstewart added inline comments to D26807: move cwnd and ssthresh updates into individual congestion control module.
Nov 18 2019
Nov 18 2019
Nov 5 2019
Nov 5 2019
Thanks for the fix @brooks