Re: svn commit: r352657 - in head/sys: conf kern modules/tcp modules/tcp/bbr netinet netinet/tcp_stacks sys

Hmm It looks like BBR needs an update too since it calls the inpcb detach of the ratelimit function too… I may need to reassess this since it should use only the tcp_ratelimit interfaces… but for now an simple ifdef will work make sure to pick up r352660 (and actually it might be best to

Re: svn commit: r352657 - in head/sys: conf kern modules/tcp modules/tcp/bbr netinet netinet/tcp_stacks sys

Right Thats because GENERIC does not add the optional TCP stacks. Ok the problem is fixed with r352659 The tcp_ratelimit.h had a mixed up ifdef i.e. #ifdef RATELIMIT #ifdef _KERNEL definitions #else macro definitions that return error #endif #endif Which should have been the opposite

Re: svn commit: r352657 - in head/sys: conf kern modules/tcp modules/tcp/bbr netinet netinet/tcp_stacks sys

Ok I have found it Its a reversal in an ifdef in tcp_ratelimit.h .. it supposed to be that if its not define (RATELIMIT) the main interfaces return errors.. and the ifdef kernel/ratelimit is reversed of what it should be. Let me fix that :) R > On Sep 24, 2019, at 12:55 PM, Randall Stewart

Re: svn commit: r352657 - in head/sys: conf kern modules/tcp modules/tcp/bbr netinet netinet/tcp_stacks sys

12.0R would not have BBR .. its only in head… hmm it could be a issue with TCP_RATELIMIT not defined though I did compile GENERIC without the extra stacks (and without rate limit and hpts) and that compiled ok.. R > On Sep 24, 2019, at 12:49 PM, Li-Wen Hsu wrote: > > On Tue, Sep 24, 2019 at

Re: svn commit: r352657 - in head/sys: conf kern modules/tcp modules/tcp/bbr netinet netinet/tcp_stacks sys

This is strange I built this and have it running on my machine with the standard make buildkern KERNCONF=myconf and make installkern KERNCONF=myconf Why can I build and it blow up.. last time I saw this I was building in amd64/compile and was getting a warning that somehow is an error.. but

Re: svn commit: r349907 - head/sys/netinet/tcp_stacks

opps.. that was a error on my part I will fix it :) > On Jul 11, 2019, at 4:37 AM, Enji Cooper wrote: > > >> On Jul 10, 2019, at 9:38 PM, Randall Stewart wrote: >> >> Author: rrs >> Date: Thu Jul 11 04:38:33 2019 >> New Revision: 349907 >> URL:

Re: svn commit: r349893 - in head/sys: modules/tcp/rack netinet netinet/tcp_stacks sys

John: Thanks for the suggestions.. I have committed changes to the two nits. As to M_PROTO1, I see that in the NF world we have removed M_PROTO12 and moved the M_PROTO’s up 1 i.e. M_PROTO1 == 0x2000 So for now it is safe, since the M_TSTMP_LRO is not yet used.. but in my up and coming commits I

Re: svn commit: r344099 - head/sys/net

> On Feb 13, 2019, at 1:10 PM, John Baldwin wrote: > > On 2/13/19 10:03 AM, Randall Stewart wrote: >> oh and one other thing.. >> >> It was *not* a random IFP.. it was the IFP to the lagg. >> >> I.e. an alloc() was done to the lagg.. and the free was >> done back to the same IFP (that

Re: svn commit: r344099 - head/sys/net

oh and one other thing.. It was *not* a random IFP.. it was the IFP to the lagg. I.e. an alloc() was done to the lagg.. and the free was done back to the same IFP (that provided the allocate). R > On Feb 13, 2019, at 1:02 PM, Randall Stewart wrote: > > I disagree. If you define an alloc it

Re: svn commit: r344099 - head/sys/net

I disagree. If you define an alloc it is only reciprocal that you should define a free. The code in question that hit this was changed (its in a version of rack that has the rate-limit and TLS code).. but I think these things *should* be balanced.. if you provide an Allocate, you should also

Re: svn commit: r334804 - in head/sys: kern modules/tcp modules/tcp/rack netinet netinet/tcp_stacks sys

> On Jun 7, 2018, at 6:01 PM, hiren panchasara > wrote: > > On 06/07/18 at 06:18P, Randall Stewart wrote: >> Author: rrs >> Date: Thu Jun 7 18:18:13 2018 >> New Revision: 334804 >> URL: https://svnweb.freebsd.org/changeset/base/334804 >> >> Log: >> This commit brings in a new refactored

Re: svn commit: r304218 - head/sys/netinet

In theory it *could* be MFC’d to stable-10 and 11 but I am not sure we want to do that. I am told by Drew that it does improve performance since in stable-10 you are getting the INFO_WLOCK() but I am not sure if folks want it MFC’d… One thing that this code leads us towards is we *in theory*

Re: svn commit: r304218 - head/sys/netinet

Hans: Take a look at the comments maybe they will help you understand whats going on. The idea of it is that you *only* need the INFO_RLOCK when the timer function wants to destroy the tcb (not all timers do this).. and yes usually the timer function is going to call the drop/close path to

Re: svn commit: r304218 - head/sys/netinet

Sure Let me add some comments for you. The idea her is that you pick-up a reference to the PCB.. so it can’t be removed. Thus when you re-lock the INP you check the dropped flag (just in case someone did get in). Let me get that in comments.. (note thats also why when using this function you

Re: svn commit: r303037 - head/sys/kern

You are most welcome to backout anything you like.. as far as I am concerned you own the code.. R > On Jul 20, 2016, at 6:35 PM, Gleb Smirnoff wrote: > > Randall, > > I have just tested and r303037 brings the TCP panic back. I > got two crashes during 2.5 hours. > > In

Re: svn commit: r303037 - head/sys/kern

Gleb I wish you would have responded earlier.. I am more than glad to hand off all kern_timeout.c to you… please take it commit what you want to it and have it. I hate the code and I dislike having to touch it. Its yours.. I can assure you I will not touch it again. R > On Jul 20, 2016, at 8:53

Re: svn commit: r302998 - head/sys/kern

Well The code itself I had up on machines for probably about 2 months. But then I switched over to Gleb’s changes here just recently .. which caused me all kinds of fun :) I had to go back into Mercurial to pull back my changes.. I have had the resurrected changes running on my netflix machines

Re: svn commit: r302998 - head/sys/kern

Glen: My changes work.. I have them running in NF in at least 1/2 dozen machines. I am more than willing to commit them.. they actually are not much different than whats in stable 10.. though I don’t know if the async-drain was MFC’d there.. it needs to be in for TCP.. or else you will have

Re: svn commit: r302998 - head/sys/kern

Gleb Ok I have now updated https://reviews.freebsd.org/D7135 You can take this or not… I really don’t care either way… (you are welcome to own the kern_timeout.c code I hate it) :-) Basically when you went off and re-factored kern_timeout.c I had worked in parallel on fixing the bugs you

Re: svn commit: r302998 - head/sys/kern

I have worked out a fix of this in Netflix code base (I have the same code running there). I will get that tested tonight I will get the fixes in to restore the behavior. I will setup a phabricator shortly.. most likely I will update the one I already have on the one problem your earlier patch

Re: svn commit: r302998 - head/sys/kern

Gleb: This now leaks TCP-PCB’s since you have broken the return codes with all your fixes that used to be in here. It was return 1 — You stopped the callout return 0 — The callout could not be stopped return -1 — The callout was not running. The LLRef code that was crashing in in.c depended on

Re: svn commit: r292309 - in head/sys: modules modules/tcp modules/tcp/fastpath netinet netinet/tcp_stacks

Ahh I think I see this is a difference between our friend clang and gcc.. since I bet ppc uses gcc not clang :-o I will have something for you in a sec.. sorry about that Ed R This is the difference between On Dec 16, 2015, at 6:00 AM, Ed Maste wrote: > On 16 December

Re: svn commit: r292309 - in head/sys: modules modules/tcp modules/tcp/fastpath netinet netinet/tcp_stacks

r292336 should take care of that let me know if it does not.. I am getting on a plane to head back from CA. to S.C. shortly but I will be online for a couple more hours :-) R On Dec 16, 2015, at 6:00 AM, Ed Maste wrote: > On 16 December 2015 at 00:56, Randall Stewart

Re: svn commit: r290664 - in head: share/man/man9 sys/kern sys/sys

On Nov 13, 2015, at 4:43 PM, Bryan Drewery wrote: > On 11/13/2015 1:24 PM, Randall Stewart wrote: >> Looking at the patch, we need a define of your >> >> _callout_stop_safe >> >> and we need to switch >> >> callout_stop()’s define to use the new _callout_stop_safe() >

Re: svn commit: r290664 - in head: share/man/man9 sys/kern sys/sys

Hmm callout_reset() returns either 0 or 1 It returns no other values and did not change.. maybe ti should say positive or one in the manual… I can add that to the fix patch. R On Nov 13, 2015, at 4:32 PM, Alexander V. Chernikov wrote: > One small note on lltable: change

Re: svn commit: r290664 - in head: share/man/man9 sys/kern sys/sys

So looking deeper something like the following (with Bryan’s patch) is in order. Though there is one place in the task code that looks funny since it was pending = !!callout_stop() I changed it to pending = !! (callout_stop > 0) But I wonder about the double !! that seems rather convoluted..

Re: svn commit: r290664 - in head: share/man/man9 sys/kern sys/sys

Strange I went looking through all calls to callout stop with cscope and saw no one paying attention to the return value… (which I thought was not good). And yes I am running this in a lot of systems. R On Nov 13, 2015, at 6:16 AM, Alexander V. Chernikov wrote: >

Re: svn commit: r290664 - in head: share/man/man9 sys/kern sys/sys

Bryan: This looks like a decent thing to do.. Still wondering why changing the callout.h header file would not have caused things to recompile to pick up the new argument.. We can do it this way though it looks fine. You want to commit it or I? R On Nov 13, 2015, at 3:48 PM, Bryan Drewery

Re: svn commit: r290664 - in head: share/man/man9 sys/kern sys/sys

My patch address the following: On Nov 13, 2015, at 4:13 PM, Alexander V. Chernikov wrote: > > > 13.11.2015, 23:59, "Randall Stewart" : >> Strange >> >> I went looking through all calls to callout stop with cscope and saw >> no one paying

Re: svn commit: r290664 - in head: share/man/man9 sys/kern sys/sys

let me fix that R On Nov 13, 2015, at 4:51 PM, Alexander V. Chernikov wrote: > 14.11.2015, 00:41, "Randall Stewart" : >> Hmm >> >> callout_reset() returns either 0 or 1 >> >> It returns no other values and did not change.. maybe ti should say positive

Re: svn commit: r290664 - in head: share/man/man9 sys/kern sys/sys

Looking at the patch, we need a define of your _callout_stop_safe and we need to switch callout_stop()’s define to use the new _callout_stop_safe() R On Nov 13, 2015, at 4:20 PM, Randall Stewart wrote: > No alexander’s panic’s are because the > LLREF > is done if

Re: svn commit: r290664 - in head: share/man/man9 sys/kern sys/sys

No alexander’s panic’s are because the LLREF is done if (callout_stop()) But now if it was not running -1 is returned.. Try the patch I just sent.. R On Nov 13, 2015, at 4:02 PM, Bryan Drewery wrote: > On 11/13/2015 1:00 PM, Randall Stewart wrote: >> Bryan: >> >> This

Re: svn commit: r290664 - in head: share/man/man9 sys/kern sys/sys

Done in 290805 R On Nov 13, 2015, at 4:51 PM, Alexander V. Chernikov wrote: > 14.11.2015, 00:41, "Randall Stewart" : >> Hmm >> >> callout_reset() returns either 0 or 1 >> >> It returns no other values and did not change.. maybe ti should say positive >>

Re: svn commit: r290714 - in head/sys/tests: callout_test framework

I thought Kib fixed that.. I was looking at it this AM and found he had beat me too it.. R On Nov 12, 2015, at 12:01 PM, Bjoern A. Zeeb wrote: > >> On 12 Nov 2015, at 10:31 , Randall Stewart wrote: >> >> Author: rrs >> Date: Thu Nov 12 10:31:14 2015 >>

Re: svn commit: r290664 - in head: share/man/man9 sys/kern sys/sys

And I disagree here Hans You don’t need that and it just adds more into the callout system that is not needed. R On Nov 10, 2015, at 9:59 AM, Hans Petter Selasky wrote: > On 11/10/15 15:49, Randall Stewart wrote: >> +#define callout_async_drain(c, d)

Re: svn commit: r287780 - in head: share/man/man9 sys/kern sys/sys

Hans: By outside prompting, I have finally had a chance to look at this: What it appears you do here is: a) stop the callout, not paying attention to if it stopped or not. b) Then get the callout systems lock and check if your callout is up and running, storing that in your retval. Where

Re: svn commit: r281510 - head/sys/kern

Crud Your right.. On Apr 13, 2015, at 7:23 PM, John Baldwin j...@freebsd.org wrote: On Monday, April 13, 2015 11:06:14 PM Randall Stewart wrote: Author: rrs Date: Mon Apr 13 23:06:13 2015 New Revision: 281510 URL: https://svnweb.freebsd.org/changeset/base/281510 Log: Restore the two

Re: svn commit: r280785 - in head/sys: kern netgraph/atm/sscop netgraph/atm/uni sys

John: Comments below.. On Mar 30, 2015, at 9:16 AM, John Baldwin j...@freebsd.org wrote: On Saturday, March 28, 2015 12:50:24 PM Randall Stewart wrote: Author: rrs Date: Sat Mar 28 12:50:24 2015 New Revision: 280785 URL: https://svnweb.freebsd.org/changeset/base/280785 Log: Change

Re: svn commit: r280785 - in head/sys: kern netgraph/atm/sscop netgraph/atm/uni sys

John: As I just said, Warner and I feel we can get by with making the int - short/short so we preserver the KPI and at the same time achieve the objective .. My big concern was no intel platforms but Warner gave me a green light there ;-) R On Mar 30, 2015, at 10:10 AM, John Baldwin

Re: svn commit: r280785 - in head/sys: kern netgraph/atm/sscop netgraph/atm/uni sys

Davide: I have had a long chat this weekend with imp, and both he and I feel the right fix is to *not* bump the version, but instead change the two fields to shorts. That way the length will still say the same so we can MFC this. I will be committing that shortly, I have it testing inside right

Re: svn commit: r280785 - in head/sys: kern netgraph/atm/sscop netgraph/atm/uni sys

John: FYI in getting this setup, NOCPU will mean callout.h will need to include sys/proc.h I hope thats ok.. either that or I need to do a #ifndef NOCPU #define NOCPU (-1) #endif.. Which seems ugly.. R On Mar 30, 2015, at 2:38 PM, John Baldwin j...@freebsd.org wrote: On Monday, March 30,

Re: svn commit: r280785 - in head/sys: kern netgraph/atm/sscop netgraph/atm/uni sys

On Mar 30, 2015, at 9:16 AM, John Baldwin j...@freebsd.org wrote: On Saturday, March 28, 2015 12:50:24 PM Randall Stewart wrote: Author: rrs Date: Sat Mar 28 12:50:24 2015 New Revision: 280785 URL: https://svnweb.freebsd.org/changeset/base/280785 Log: Change the callout to supply -1 to

Re: svn commit: r278472 - in head/sys: netinet netinet6

Gleb: Ok here is the diff of the arp timer function that this changed made (238990): arptimer(void *arg) { + struct llentry *lle = (struct llentry *)arg; struct ifnet *ifp; - struct llentry *lle; - int pkts_dropped; + size_t

Re: svn commit: r278472 - in head/sys: netinet netinet6

On Feb 13, 2015, at 4:21 PM, Gleb Smirnoff gleb...@freebsd.org wrote: On Mon, Feb 09, 2015 at 03:11:21PM -0500, John Baldwin wrote: J On Monday, February 09, 2015 07:28:12 PM Randall Stewart wrote: J Author: rrs J Date: Mon Feb 9 19:28:11 2015 J New Revision: 278472 J URL: