Hello, I haven''t been keeping up with sending ESFQ [ANNOUNCE] messages to this list, but I''ve still been working on the patch. If you''re curious about recent changes, take a look at the home page, ChangeLog, and README: http://fatooh.org/esfq-2.6/ http://fatooh.org/esfq-2.6/current/ChangeLog http://fatooh.org/esfq-2.6/current/README Meanwhile, I''m interested in finally getting ESFQ included in the Linux kernel. Before I start sending patches and requesting maintainer review, however, there''s one question I want to ask current or potential users of SFQ and ESFQ: Should ESFQ be merged into SFQ or remain as a separate qdisc? Note that I can''t promise either is an option, since I haven''t queried any maintainers yet; I''d rather have a clear idea of what is more desirable to the users before I propose anything. Of course, if any maintainers read this, I would value their input at this point as well. Here are some advantages and disadvantages of merging ESFQ with SFQ. Please correct me or let me know of any others you think of. ---Advantages--- * There''s nothing radically different about ESFQ. A separate sch_esfq.c would duplicate lots of the code in sch_sfq.c. * Current users of SFQ would benefit from the better hashing of using jhash. Other than that, the default parameters of ESFQ are the same as SFQ''s hardcoded values, so ESFQ would be a drop-in replacement. * Having two similar-looking similarly-functioning qdiscs could be confusing for new users. ---Disadvantages--- * SFQ has been stable for years; it may be undesirable to make changes that could potentially introduce bugs. * ESFQ is marginally slower than SFQ (although I haven''t been able to measure a practical difference; if someone has benchmark tips I''ll try them). -Corey
Corey Hickey wrote:> Meanwhile, I''m interested in finally getting ESFQ included in the Linux > kernel.Patrick McHardy recently changed sfq to be more like esfq. http://marc.info/?l=linux-netdev&m=118051806814780&w=2 Andy.
Corey Hickey wrote:> Hello, > > I haven''t been keeping up with sending ESFQ [ANNOUNCE] messages to this > list, but I''ve still been working on the patch. If you''re curious about > recent changes, take a look at the home page, ChangeLog, and README: > > http://fatooh.org/esfq-2.6/ > http://fatooh.org/esfq-2.6/current/ChangeLog > http://fatooh.org/esfq-2.6/current/README > > Meanwhile, I''m interested in finally getting ESFQ included in the Linux > kernel. Before I start sending patches and requesting maintainer review, > however, there''s one question I want to ask current or potential users > of SFQ and ESFQ: > > Should ESFQ be merged into SFQ or remain as a separate qdisc?I''ve CCed netdev. I think merging parts of ESFQ (dynamic depth and flow number) would make a lot of sense, but I''m intending to submit an alternative to the ESFQ hashing scheme for 2.6.23: http://www.mail-archive.com/netdev@vger.kernel.org/msg39156.html I have enough trust in ESFQ''s stability that I don''t think we need a new qdisc for this and could merge it in SFQ (and the "uses only 1 page" justification isn''t true anymore anyway), but I also wouldn''t mind adding a new qdisc.> Note that I can''t promise either is an option, since I haven''t queried > any maintainers yet; I''d rather have a clear idea of what is more > desirable to the users before I propose anything. Of course, if any > maintainers read this, I would value their input at this point as well. > > Here are some advantages and disadvantages of merging ESFQ with SFQ. > Please correct me or let me know of any others you think of. > > ---Advantages--- > * There''s nothing radically different about ESFQ. A separate sch_esfq.c > would duplicate lots of the code in sch_sfq.c. > * Current users of SFQ would benefit from the better hashing of using > jhash. Other than that, the default parameters of ESFQ are the same > as SFQ''s hardcoded values, so ESFQ would be a drop-in replacement. > * Having two similar-looking similarly-functioning qdiscs could be > confusing for new users. > > ---Disadvantages--- > * SFQ has been stable for years; it may be undesirable to make changes > that could potentially introduce bugs. > * ESFQ is marginally slower than SFQ (although I haven''t been able to > measure a practical difference; if someone has benchmark tips I''ll try > them).- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patrick McHardy wrote:> Corey Hickey wrote: >> Hello, >> >> I haven''t been keeping up with sending ESFQ [ANNOUNCE] messages to this >> list, but I''ve still been working on the patch. If you''re curious about >> recent changes, take a look at the home page, ChangeLog, and README: >> >> http://fatooh.org/esfq-2.6/ >> http://fatooh.org/esfq-2.6/current/ChangeLog >> http://fatooh.org/esfq-2.6/current/README >> >> Meanwhile, I''m interested in finally getting ESFQ included in the Linux >> kernel. Before I start sending patches and requesting maintainer review, >> however, there''s one question I want to ask current or potential users >> of SFQ and ESFQ: >> >> Should ESFQ be merged into SFQ or remain as a separate qdisc? > > I''ve CCed netdev. I think merging parts of ESFQ (dynamic depth and > flow number) would make a lot of sense, but I''m intending to submit > an alternative to the ESFQ hashing scheme for 2.6.23: > > http://www.mail-archive.com/netdev@vger.kernel.org/msg39156.htmlNice. I wasn''t aware of that. Your patch looks like it supersedes ESFQ''s hashing, so, if it gets applied, that already removes a large chunk of the differences between SFQ and ESFQ. If I don''t hear any opposition, then I''ll keep an eye out for when your patch gets accepted (assuming it does) and then submit patch(es) porting the rest of ESFQ''s features to SFQ. I just subscribed myself to netdev.> I have enough trust in ESFQ''s stability that I don''t think we need > a new qdisc for this and could merge it in SFQ (and the "uses only > 1 page" justification isn''t true anymore anyway), but I also > wouldn''t mind adding a new qdisc.Thanks for the trust; I''m sure that the patches will have to undergo some cleanup either way, considering my newbieness to kernel development. -Corey
Corey Hickey wrote:> Patrick McHardy wrote: >>> >>> Should ESFQ be merged into SFQ or remain as a separate qdisc? >>> >> I''ve CCed netdev. I think merging parts of ESFQ (dynamic depth and >> flow number) would make a lot of sense, but I''m intending to submit >> an alternative to the ESFQ hashing scheme for 2.6.23: >> >> http://www.mail-archive.com/netdev@vger.kernel.org/msg39156.html >> > > Nice. I wasn''t aware of that. Your patch looks like it supersedes ESFQ''s > hashing, so, if it gets applied, that already removes a large chunk of > the differences between SFQ and ESFQ. > > If I don''t hear any opposition, then I''ll keep an eye out for when your > patch gets accepted (assuming it does) and then submit patch(es) porting > the rest of ESFQ''s features to SFQ. >I think it would be best if you would start posting patches to add the missing features (without the hash changes) to SFQ, if you''re quick this may already go in during the 2.6.23 merge window. My changes are mostly independant of yours, if there are any clashes the one who goes last will just have to rediff their patches :) Since you need to pass additional parameters to SFQ for your changes, have a look at my rtnetlink compat attribute patch: http://article.gmane.org/gmane.linux.network/64851 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patrick McHardy wrote:> Corey Hickey wrote: >> Patrick McHardy wrote: >>>> Should ESFQ be merged into SFQ or remain as a separate qdisc? >>>> >>> I''ve CCed netdev. I think merging parts of ESFQ (dynamic depth and >>> flow number) would make a lot of sense, but I''m intending to submit >>> an alternative to the ESFQ hashing scheme for 2.6.23: >>> >>> http://www.mail-archive.com/netdev@vger.kernel.org/msg39156.html >>> >> Nice. I wasn''t aware of that. Your patch looks like it supersedes ESFQ''s >> hashing, so, if it gets applied, that already removes a large chunk of >> the differences between SFQ and ESFQ. >> >> If I don''t hear any opposition, then I''ll keep an eye out for when your >> patch gets accepted (assuming it does) and then submit patch(es) porting >> the rest of ESFQ''s features to SFQ. >> > > I think it would be best if you would start posting patches > to add the missing features (without the hash changes) to SFQ, > if you''re quick this may already go in during the 2.6.23 merge > window. My changes are mostly independant of yours, if there > are any clashes the one who goes last will just have to rediff > their patches :) > > Since you need to pass additional parameters to SFQ for your > changes, have a look at my rtnetlink compat attribute patch: > > http://article.gmane.org/gmane.linux.network/64851Ok, I''ll work on it later. Thanks. -Corey - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html