Unless I'm mistaken this is several fixes, not all of which are related to CUBIC, but contained in a single patch. Please split these out into separate changes, in particular the mathematical equation change in cc_cubic.h. While I believe that the math change there is correct (from reading the latest draft) I'd like it to be possible to revert that one change simply if it proves to be an issue.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 6 2016
Nov 28 2016
Nov 23 2016
Nov 19 2016
Nov 18 2016
Nov 5 2016
Nov 3 2016
A few of us discussed this today in the transport conference call. hps@ will have an update based on that discussion. The gist is that np@, hps@ and other NIC facing folks should make the decision on how to use the fields.
Oct 28 2016
I think this is a good addition.
Oct 22 2016
I am confused by the question about the manual page. That can be put under a separate review if you like.
Oct 19 2016
We have 100G hardware at Sentex on the Mercats. I can free those hosts up for you.
A quick note that function calls are definitely the preferred solution.
Oct 17 2016
Looks good to me. I can commit this if you like.
Oct 11 2016
Oct 10 2016
Oct 7 2016
Oct 5 2016
Address comments from markj@
Oct 3 2016
LGTM
Oct 1 2016
Do we have a document on how the packaging for base works? I'd like to understand the process a bit better before approving this review.
Sep 30 2016
I'd like a reference to what these will actually do. It seems that each library is now a package but that may not make sense based on the structure of those libraries.
Sep 28 2016
I'd prefer a broad, cleanup commit.
This looks correct to me.
Sep 24 2016
Sep 20 2016
Sep 15 2016
I will test and commit this one.
Sep 14 2016
Sep 12 2016
Sep 3 2016
I've address the main issues.
Sep 2 2016
Address issue of too many threads.
Add support for using cpuset to spearate forked processes.
Remove dead code.
Aug 30 2016
Aug 29 2016
Address more comments.
Aug 25 2016
Committed revision 304825.
jhb@ reports that if p_args is non 0 then ar_args will be valid.
Tighten up the logic.
Aug 23 2016
I guess my other fear is that the address might overlap an existing allocation. What is the use case for random MACs?
I am somewhat confused. I don't see anything about random addresses in the RFC mentioned in the followup.
There is no reason for the functions to be static at all, so removing them just cleans up the code and makes it trivially debuggable.
Aug 22 2016
Aug 18 2016
Add the version update
Aug 17 2016
Address issues pointed out by brooks@
Chuck this one because arc.
Remove the obsolete opebsd_poll system call.
Aug 16 2016
A few points about how we put code into FreeBSD.
Aug 11 2016
Aug 2 2016
Address issue pointed out by markj
Jul 29 2016
Jul 27 2016
Accepted. Go for it.
Jul 25 2016
Jul 11 2016
Jul 8 2016
I'll make that change in the commit.