Re: [LARTC] ESFQ: request for user input

Re: [LARTC] ESFQ: request for user input

[Patrick McHardy]

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).

Re: ESFQ: request for user input

[Corey Hickey]

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.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 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

Re: [LARTC] ESFQ: request for user input

[Patrick McHardy]

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

Re: [LARTC] ESFQ: request for user input

[Corey Hickey]

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/64851

Ok, I'll work on it later. Thanks.

-Corey