Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL

[Krzysztof Matusik <kyf@arterm.pl>]

Dnia wtorek, 20 czerwca 2006 17:16, Patrick McHardy napisał:
> jamal wrote:
> > On Tue, 2006-20-06 at 03:04 +0200, Patrick McHardy wrote:
> >>It would be nice to have support for HFSC as well, which unfortunately
> >>needs to be done in the kernel since it doesn't use rate tables.
> >>What about qdiscs like SFQ (which uses the packet size in quantum
> >>calculations)? I guess it would make sense to use the wire-length
> >>there as well.
> >
> > Didnt even think of that ;->
> > Is it getting too complicated?
>
> The code wouldn't be very complicated, it just adds some overhead. If
> you do something like I described in my previous mail the overhead for
> people not using it would be an additional pointer test before reading
> skb->len. I guess we could also make it a compile time option.
> I personally think this is something that really improves our quality
> of implementation, after all, its "wire" resources qdiscs are meant
> to manage.

I'd love to see this one implemented. I'm using HFSC more than a year and it 
never provides proper QoS on ATM/ADSL links; low delays can never be achieved 
even with significant throttling below the h/w link bandwidth.
This would help a lot regarding the amount of adsl users but on the other 
hand- there's not many HFSC implementations in real-life I guess (users seem 
to be afraid of it's 'complexity'). 
This idea doesn't seem look dirty- is there a chance to implement it in the 
kernel and iproute?

regards