netdev - Re: [RFC] sched: CHOKe packet scheduler (v0.6)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1294853590.3981.105.camel@edumazet-laptop>
Date:	Wed, 12 Jan 2011 18:33:10 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [RFC] sched: CHOKe packet scheduler (v0.6)

Le mercredi 12 janvier 2011 à 09:27 -0800, Stephen Hemminger a écrit :
> On Wed, 12 Jan 2011 08:13:48 +0100
> Eric Dumazet <eric.dumazet@...il.com> wrote:
> 
> > Hi Stephen, here is my v0.6 version :
> > 
> > - Added sanity checks before kcalloc()/kzalloc()
> > - Added a __GFP_NOWARN to kcalloc()
> > - Added call to qdisc_bstats_update() after commit bfe0d0298f2a67d94d5
> > (net_sched: factorize qdisc stats handling)
> > 
> > TODO :
> > - Added a stat specific update to track CHOKe probabilistic dual-drops
> >   I temporarily use requeues counter to make sure our code works
> 
> I am going to redo stats and config.
> Should thresholds be packet or byte based? I prefer packet
> Also leaning towards merging qmax and qlimit together.

I believe CHOKe spirit is per packet, I agree with you.

(This makes the tab[] array sizing directly depends on ctl->limit, not
on a computation ctl->limit/smallest_packet_size)

Not sure we can merge qmax and qlimit, are you sure its OK with CHOKe
paper and experimental results ?
(Sorry I cant spend too much time right now to check this point)



--
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