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 inclu
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
#i
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 wro
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 9
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 this
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: https://svnweb.freebsd.org/changeset/base/34990
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 w
> 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 provide
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 is
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 provi
> 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 TC
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* co
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 purge
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
have
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 your email [1] you are
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
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
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 yet
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 were
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 di
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
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 wrote:
>> Author: rrs
>>
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 2015 at 00:56, Randall S
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
>> or one in the manual…
>>
>> I can
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
>> or one in the manual…
>>
>> I can
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()
>
> For both cases, there
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 in nd6_llinfo_setti
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 attention to the return value… (which I thought w
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 (callout_stop())
>
> But now
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 looks like a decent thin
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..
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 wro
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:
> 10.11.2015, 17:49, "Randall
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
>> New Revision: 290714
>> URL: https://sv
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) \
>> +
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 1
Crud
Your right..
On Apr 13, 2015, at 7:23 PM, John Baldwin 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 l
On Mar 30, 2015, at 9:16 AM, John Baldwin 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 i
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 wrote:
> On Monday, March 30, 2015 11:16:20 AM
John:
Comments below..
On Mar 30, 2015, at 9:16 AM, John Baldwin 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
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 wrote:
>
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 n
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 pkts_dro
On Feb 13, 2015, at 4:21 PM, Gleb Smirnoff 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: https://svnweb.f
44 matches
Mail list logo
