On Sat, 2016-06-11 at 19:41 +0300, Jonathan Morton wrote:
> > On 11 Jun, 2016, at 12:11, Kevin Darbyshire-Bryant
> > wrote:
> >
> > And now there's a version 2 of Eric's fix:
> > http://marc.info/?l=linux-netdev&m=146507012302643&w=2
> >
> > Does this change apply to cake?
>
> I suppose this
Eric:
Quick side question (from trying to understand the qdisc locking fixes
you recently landed in net-next)
In the sqm-scripts, we are usually in a position where we are doing
both inbound and outbound rate limiting (htb + fq_codel or cake). We
typically run out of cpu or have mis-behavior on t
On Sun, 2016-06-12 at 09:40 -0700, Dave Taht wrote:
> Eric:
>
> Quick side question (from trying to understand the qdisc locking fixes
> you recently landed in net-next)
>
> In the sqm-scripts, we are usually in a position where we are doing
> both inbound and outbound rate limiting (htb + fq_cod
> On 12 Jun, 2016, at 20:48, Eric Dumazet wrote:
>
>> A) In my failing to make sense of all the dialog around these patches
>> ( https://lwn.net/Articles/687617/ ), it sounds like this (inbound
>> and outbound) processing are still locked to a single thread,
>> essentially?
>
> Om a router, th
>> And there’s also the problem that we might not need to drop packets as
>> large as the incoming packet in order to fit the latter into the queue
>> - so this corrected correction may be *negative* (the queue is longer
>> than before) - but qdisc_tree_reduce_backlog() only takes an unsigned
>> pa
On Sun, 2016-06-12 at 20:51 +0300, Jonathan Morton wrote:
> > On 12 Jun, 2016, at 20:48, Eric Dumazet wrote:
> >
> >> A) In my failing to make sense of all the dialog around these patches
> >> ( https://lwn.net/Articles/687617/ ), it sounds like this (inbound
> >> and outbound) processing are st
On Sun, 2016-06-12 at 20:59 +0300, Jonathan Morton wrote:
> Not so - unless you are very sure that q->backlog is the same size as
> quantity.
Obviously this is the case in all linux kernels so far.
If someone plans to change this at one point, then yes, he/she has to
fix this.
> In an increas
4GiB back log is several orders of magnitude more than what you want for a
100Gb link. Unless you think this algorithm will be used for 1Zb/s links.
64bit is a bit overkill
On Jun 12, 2016 2:04 PM, "Eric Dumazet" wrote:
> On Sun, 2016-06-12 at 20:59 +0300, Jonathan Morton wrote:
>
> > Not so - un
