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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
