[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55533321.302@mojatatu.com>
Date: Wed, 13 May 2015 07:18:57 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Florian Westphal <fw@...len.de>
CC: netdev@...r.kernel.org
Subject: Re: [PATCH -next] net: sched: use counter to break reclassify loops
On 05/12/15 09:00, Florian Westphal wrote:
> Jamal Hadi Salim <jhs@...atatu.com> wrote:
>> Florian,
>> In general i am in support of removing this - since the use case never
>> materialized as being useful. However, this is not the same logic that
>> was there before. To get equivalency you need to pass the limit into
>> tc_classify_compat() so i can be reset.
>
> AFAICS this re-set only happens when we return something other
> than RECLASSIFY which means the caller will not check the limit.
>
> So in fact it should be ok to remove this since the counter will always
> start from 0 on next tc_classify() invocation.
>
Florian, consider the following scenario:
Assume X is the max allowed reclassified before bells start ringing.
If we see upto X back-to-back reclassify - we are very much likely in
a loop. We should see fire trucks arrive and bail out.
If we see X-1 "reclassify" followed by a "pipe" followed by
X-1 "reclassify" followed by "ok" then that looks like a healthy
policy. But that is a a total of 2X-2 reclassifies. You will
bail out at X reclassifies; what i am saying is you shouldnt.
And existing logic doesnt. Does that make sense?
Pass the &limit and reset it as before to 0 when you see something
other than reclassify.
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists