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
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
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
>> 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 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
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
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 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
> 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 answers the question of which packet’s size should be used in
the correcti
On 07/06/16 16:05, Kevin Darbyshire-Bryant wrote:
On 07/06/16 15:50, Jonathan Morton wrote:
On 7 Jun, 2016, at 14:20, Kevin Darbyshire-Bryant
wrote:
I had a nose at CAKE but couldn't quit work out if a similar issue
is present but I suspect it is. Certainly if Eric can't get it right
"M
On 07/06/16 15:50, Jonathan Morton wrote:
On 7 Jun, 2016, at 14:20, Kevin Darbyshire-Bryant
wrote:
I had a nose at CAKE but couldn't quit work out if a similar issue is present but I
suspect it is. Certainly if Eric can't get it right "My prior attempt to fix the
backlogs of parents failed
> On 7 Jun, 2016, at 14:20, Kevin Darbyshire-Bryant
> wrote:
>
> I had a nose at CAKE but couldn't quit work out if a similar issue is present
> but I suspect it is. Certainly if Eric can't get it right "My prior attempt
> to fix the backlogs of parents failed." then it's not an 'obvious to s
Hi All,
I was nosing through linux-netdev last night when I saw this fix for
qdisc backlog reporting issues with NET_XMIT_CN in fq_codel:
http://marc.info/?l=linux-netdev&m=146506223800713&w=2
I had a nose at CAKE but couldn't quit work out if a similar issue is
present but I suspect it is.
13 matches
Mail list logo
