[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1180541401.4109.72.camel@localhost>
Date: Wed, 30 May 2007 12:10:01 -0400
From: jamal <hadi@...erus.ca>
To: Patrick McHardy <kaber@...sh.net>
Cc: netdev@...r.kernel.org
Subject: Re: [RFC NET_SCHED 00/02]: Flexible SFQ flow classification
On Wed, 2007-30-05 at 17:27 +0200, Patrick McHardy wrote:
> jamal wrote:
> Sure. The thing I don't like about the predefined hash functions is
> that its unflexible.
>
agreed.
> > skb->prio as a selector. I think if you removed that it should be fine.
>
> I don't think thats a problem, it needs to point to the correct major
> to have any effect, which can only happen if it is set by the user.
> I would prefer to keep it for consistency with other qdiscs.
>
> > Another alternative is to create a brand new FQ qdisc and leave the
> > classification to the classifiers.
>
> I created a new classifier to leave classification to the classifiers ..
> Not sure exactly why I would need a new qdisc to do that :)
>
The caveat/difference with current SFQ is you have allowed the user to
define which queue is selected. It is/was dynamically selected based on
packet header now/before. Thats the main reason i said maybe you
separate the two components totaly. i.e while FQ is useful on its own
and can use other classifiers; a useful classifier IMO for SFQ is one
that rips out the sfq_hash or whatever other schemes used in ESFQ into a
classifier (I suppose then the user can select which hash is used). In
such a classifier you can restore the pertub into it.
I am not sure i made sense.
> > I am almost tempted to say go back and write a qdisc called FQ.
>
>
> Funny, last the this came up you suggested to do basically exactly
> what this classifier does, which I thought made sense :)
>
> http://www.mail-archive.com/netdev@vger.kernel.org/msg06801.html
I am almost sensing i am contradicting myself in that thread;-> It is
hard to tell and i admit to being forgetful - but what i probably meant
is what i said above.
cheers,
jamal
-
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
Powered by blists - more mailing lists