public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [RFC] sched: CHOKe packet scheduler (v0.2)
Date: Mon, 10 Jan 2011 18:45:11 +0100	[thread overview]
Message-ID: <1294681511.3491.21.camel@edumazet-laptop> (raw)
In-Reply-To: <20110110093123.5431b368@nehalam>

Le lundi 10 janvier 2011 à 09:31 -0800, Stephen Hemminger a écrit :
> On Mon, 10 Jan 2011 14:46:50 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 
> > Le jeudi 06 janvier 2011 à 20:55 -0800, Stephen Hemminger a écrit :
> > 
> > > 
> > > The problem is that large tables of pointers in kernel require either
> > > contiguous allocation or some indirect table algorithm.
> > > 
> > 
> > Here is a v3 version with an array based queue for O(1) peek_random
> > complexity.
> > 
> > Could you send the iproute2 patch so that I can test it ?
> > 
> > Thanks !
> > 
> > 
> > diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
> > index e69de29..ea9db00 100644
> > --- a/net/sched/sch_choke.c
> > +++ b/net/sched/sch_choke.c
> > @@ -0,0 +1,388 @@
> > +/*
> > + * net/sched/sch_choke.c	CHOKE scheduler
> > + *
> > + * Copyright (c) 2011 Stephen Hemminger <shemminger@vyatta.com>
> > + * Copyright (c) 2011 Eric Dumazet <eric.dumazet@gmail.com>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * version 2 as published by the Free Software Foundation.
> > + *
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/types.h>
> > +#include <linux/kernel.h>
> > +#include <linux/skbuff.h>
> > +#include <linux/reciprocal_div.h>
> > +#include <net/pkt_sched.h>
> > +#include <net/inet_ecn.h>
> > +#include <net/red.h>
> > +
> > +/*	CHOKe stateless AQM for fair bandwidth allocation
> > +        =================================================
> > +
> > +   CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for
> > +   unresponsive flows) is a variant of RED that penalizes misbehaving flows but
> > +   maintains no flow state. The difference from RED is an additional step
> > +   during the enqueuing process. If average queue size is over the
> > +   low threshold (qmin), a packet is chosen at random from the queue.
> > +   If both the new and chosen packet are from the same flow, both
> > +   are dropped. Unlike RED, CHOKe is not a "classful" qdisc because it
> > +   needs to access packets in queue randomly.
> > +
> > +   Source:
> > +   R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
> > +   Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
> > +   IEEE INFOCOM, 2000.
> > +
> > +   A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
> > +   Characteristics", IEEE/ACM Transactions on Networking, 2004
> > +
> > + */
> > +
> > +struct choke_sched_data {
> > +	u32		 limit;
> > +	unsigned char	 flags;
> > +
> > +	struct red_parms parms;
> > +	struct red_stats stats;
> > +
> > +	unsigned int	 head;
> > +	unsigned int	 tail;
> > +	unsigned int	 holes;
> > +	unsigned int	 tab_mask; /* size - 1 */
> > +	struct sk_buff **tab;
> > +};
> > +
> > +static inline unsigned int choke_len(const struct choke_sched_data *q)
> > +{
> > +	return (q->tail - q->head) & q->tab_mask;
> > +}
> > +
> > +/* deliver a random number between 0 and N - 1 */
> > +static inline u32 random_N(unsigned int N)
> > +{
> > +	return reciprocal_divide(random32(), N);
> > +}
> > +
> > +/* Select a packet at random from the queue in O(1) */
> > +static struct sk_buff *choke_peek_random(struct choke_sched_data *q, unsigned int *pidx)
> > +{
> > +	*pidx = (q->head + random_N(choke_len(q))) & q->tab_mask;
> > +	return q->tab[*pidx];
> > +}
> 
> I don't think this works right. The choke_peek_random could find a hole.
> Either the data structure has to change, or the peek_random has to retry,
> or if quick peek fails then compress the slot with memmove and retry.
> 
> 

Yes, this "compress only if peek_random() finds a hole seems good, I'll
try this.

As number of holes is known, we could have :

if (holes_proportion_is_less_than_20_percent())
	try another random number X times
else
	compress table to remove holes.




  reply	other threads:[~2011-01-10 17:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05  0:29 [RFC] sched: CHOKe packet scheduler Stephen Hemminger
2011-01-05  6:02 ` Eric Dumazet
2011-01-05  6:19 ` Eric Dumazet
2011-01-05 17:17   ` Stephen Hemminger
2011-01-05 17:25     ` Eric Dumazet
2011-01-05 19:21       ` [RFC] sched: CHOKe packet scheduler (v0.2) Stephen Hemminger
2011-01-05 20:06         ` Eric Dumazet
2011-01-05 20:15           ` Stephen Hemminger
2011-01-06  4:07         ` Eric Dumazet
2011-01-06  6:53           ` Stephen Hemminger
2011-01-07  4:55           ` Stephen Hemminger
2011-01-07  5:39             ` Changli Gao
2011-01-07  7:10               ` Stephen Hemminger
2011-01-07  8:37             ` Eric Dumazet
2011-01-10 13:46             ` Eric Dumazet
2011-01-10 17:31               ` Stephen Hemminger
2011-01-10 17:45                 ` Eric Dumazet [this message]
2011-01-10 23:44               ` [RFC] sched: CHOKe packet scheduler (v0.4) Stephen Hemminger
2011-01-11  0:00                 ` Eric Dumazet
2011-01-11  1:10                   ` Stephen Hemminger
2011-01-11  6:18                     ` Eric Dumazet
2011-01-11  6:34                       ` Eric Dumazet
2011-01-11 23:48                         ` Stephen Hemminger
2011-01-12  0:04                           ` Eric Dumazet
2011-01-12  7:13                         ` [RFC] sched: CHOKe packet scheduler (v0.6) Eric Dumazet
2011-01-12 17:27                           ` Stephen Hemminger
2011-01-12 17:33                             ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1294681511.3491.21.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox