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