[Click] dynamically create/destroy queues for advanced scheduling

Paine, Thomas Asa PAINETA at uwec.edu
Mon Nov 27 15:31:22 EST 2006


Nicola,
        No, you shouldn't need N output queues.  My element has one input and one output port.  Each pull request pulls from the "active queue", which is set by the DRR algorithm, this takes care of your fairness need.  With prioritization, using an IPClassifier to split your traffic paths up is right.  Ultimately running the paths into your scheduler(s) or whatever other elements you want to first (possibly a separate DRR element for each "class" of traffic).

        In short, the N queues are stored in a single DRR element, the DRR element has only one input and one output, and the DRR element is a PUSH_TO_PULL so it implements both push() and pull() methods.

Thanks,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Thomas Paine (paineta at uwec.edu)
   University of Wisconsin - Eau Claire
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 -----Original Message-----
From: Nicola Arnoldi [mailto:nicola.arnoldi at dit.unitn.it]
Sent: Monday, November 27, 2006 2:00 PM
To: Paine, Thomas Asa
Subject: Re: [Click] dynamically create/destroy queues for advanced scheduling

Thanks Thomas!
I knew about DRR.
Anyway, as I am trying to provide both fairness and traffic prioritization, the problem is that I have to keep N queues where N is the number of active flows at my router.
At first I classify the traffic on a ToS basis.
Then I have to keep a single queue for each flow passing by and then I schedule them with DRR.
The problem is that if I have N queues (it's ok, they come from a pool), does my element need to have N output ports connected to the DRR scheduler?
I think it is not feasible, the number of ports has to be static!

I hope you understood my problem.


Paine, Thomas Asa ha scritto:
> Nicola,
>         I implemented a Deficit Round Robin queuing element (PUSH_TO_PULL).  DRR provides byte for byte fair queuing without the need to schedule each queue.
>         I implemented the element using a map and queue pool.  Mine is currently IP based.  You could certainly make something flow based.  The queues come from a pool, so unless the demand calls for more, the pool's size doesn't need to grow (alleviating the need for repeated memory allocation).  Queues (pointers) are then just recycled as IP traffic comes and goes.
>
> DRR (http://en.wikipedia.org/wiki/Deficit_round_robin)
>
> Thanks,
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    Thomas Paine (paineta at uwec.edu)
>    University of Wisconsin - Eau Claire
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> -----Original Message-----
> From: click-bounces at pdos.csail.mit.edu
> [mailto:click-bounces at pdos.csail.mit.edu] On Behalf Of Nicola Arnoldi
> Sent: Monday, November 27, 2006 1:25 PM
> To: click at pdos.csail.mit.edu
> Subject: [Click] dynamically create/destroy queues for advanced
> scheduling
>
> Hello everybody!
>
> Anyone tried to implement an advanced scheduler (like WFQ or similar) in which a queue has to be associated to every flow traversing the router?
>
> Is there a clever way to do it or do I have to allocate a queue every time I receive a packet from a new source?
>
> How do I dynamically allocate queues and schedule them?
>
> Thanks everybody!
> --
> ----------------------------------------
> Nicola Arnoldi
> ----------------------------------------
> MSN:   dustnic82 at hotmail.com
> Skype: nicola.arnoldi
> ----------------------------------------
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>

--
----------------------------------------
Nicola Arnoldi
----------------------------------------
MSN:   dustnic82 at hotmail.com
Skype: nicola.arnoldi
----------------------------------------



More information about the click mailing list