* David S. Miller <[EMAIL PROTECTED]> 2005-08-23 09:15 > There are actually some non-trivial issues wrt. this. We would > need to loop inside of the packet scheduler, and netfilter, to do > correct traffic classification and firewalling. > > But I guess we could deal with that by supporting chaining in > those subsystems. It looks ugly though, what to do if the > first packet is marked as "delay" by the packet scheduler, > but the rest are allowed to pass through to the device right > now? Do we unlink the one which will be delayed?
It's non-trivial to make a statement on this, it heavly depends on the complexity of the qdiscs being used. I guess the majority which would actually benefit from this chaining is not interested in classification by packet inspection but rather if at all only based on dscp so at least the whole chain could be enqueued into the same queue/band at first. I hardly think chaining will be of use at all if a certain level of congestion is reached so it should be possible to keep the queues mostly empty. Setting txqlen of the device to 2*MAX_CHAINLEN should be sufficient in most cases. We'd probably have to modify the kick/watchdog a bit to actually get the packets out faster because the enqueue()s would happen less frequently, would have to look into this. - 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
