[Top] [All Lists]

Re: dummy as IMQ replacement

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: dummy as IMQ replacement
From: Thomas Graf <tgraf@xxxxxxx>
Date: Wed, 2 Feb 2005 16:55:43 +0100
Cc: netdev@xxxxxxxxxxx, Nguyen Dinh Nam <nguyendinhnam@xxxxxxxxx>, Remus <rmocius@xxxxxxxxxxxxxx>, Andre Tomt <andre@xxxxxxxx>,, Andy Furniss <andy.furniss@xxxxxxxxxxxxx>, Damion de Soto <damion@xxxxxxxxxxxx>
In-reply-to: <>
References: <1107189625.1076.77.camel@jzny.localdomain> <> <1107202715.1075.559.camel@jzny.localdomain> <> <1107259361.1095.584.camel@jzny.localdomain> <> <1107263612.1095.598.camel@jzny.localdomain> <> <1107354293.1105.85.camel@jzny.localdomain> <>
Sender: netdev-bounce@xxxxxxxxxxx
>   tc_index: May contain a dscp value if dsmark is told to fetch the dscp
>             field, the minor part of priority if dsmark is told to map
>             priority values via handle values, or the minor part of the
>             classid in a classifier result via ingress classification or
>             a classifier attached to a dsmark. cls_tcindex, gred, and
>             meta ematch use it as input value.

Assuming we use tc_index to provide the hash...

- we don't need to worry about any definitions. tc_index already stands for
  some kind of index grouping together various packets.
- we can directly use sfq to do fair queueing on dscp values and skb
  priority including specialized map with a underlying dsmark or cls_tcindex.

<Prev in Thread] Current Thread [Next in Thread>