Hi, only a few notes on the theme. You are right with the displacement and bad enqueue byte counters. Maybe it would be better to cound packets at dequeue time only in clasfull qdisc. It also makes better sense because qdosc can also instruct SFQ to drop packet - this drop is then not decremented from HTB/CBQ's stats. HTB uses enqueue time counting because CBQ does it too and at very begining I based my work on CBQ. Seems it is time to change things. Another important info: you really CAN'T drop packets in dequeue routine if you don't want to fool classfull parent. Many logic in CBQ/HTB/ATM/PRIO qdisc is based on the existence of backlog. When you drop in dequeue, parent will think that he itself still has some packets somewhere (in children) and will constantly attempt to find them. And will be confused by the fact that it can't. Enqueue routine can give you confirmation of packet enqueue, drop routine the same. Only dequeue can't say hey there is your skb and by the way two others was dropped. What a pity. SOLUTIONS: One way is to monitor (store) q.qlen variable of all children of classfull qdisc. When I call enqueue/drop/dequeue on it I'll see its discrepancy agains last stored value and will update my counter accordingly. In the same way we could add q.bytelen and then we would be able to do the same for bytes - but this is not neccessary probably as we need to know only bytes dequeued ... There is other way - add parameter to dequeue routine which tells us how many packets we should out qlen decrease by. But I think that former approach is simpler and prone to "silent" drops (for example by some timer). Don do you plan to implement these corrections for CBQ/PRIO ? I'll do the change for HTB. devik On Sat, 4 May 2002, Don Cohen wrote: > > I notice one other small problem with my modified version of SFQ. > The fact that packets can be dropped at dequeue time is incompatible > with the way HTB (and probably CBQ and others modeled on it) keep > statistics. When I fill a low rate queue causing packets to expire > and be dropped at dequeue I get interesting statistics like this: > > This is my variant of SFQ > qdisc plfq 8016: dev eth1 > ... > Sent 17468 bytes 166 pkts (dropped 833, overlimits 0) > ... > qdisc htb 1: dev eth1 r2q 10 default 2 dcache 0 > deq_util 1/1000000 deq_rate 0 trials_per_deq 0 > dcache_hits 0 direct_packets 0 > Sent 32626 bytes 309 pkts (dropped 690, overlimits 1126) > backlog 143p > > Note that plfq, which is inside of htb, thinks it has dropped more > packets than htb has. The reason is that htb considers a packet to be > "sent" when it's enqueued. I notice in retrospect that even with > current SFQ, the statistics are not correct. The reason is that it's > possible to successfully enqueue packet#1 (at which point HTB adds its > length to the number of bytes "sent)", then fail to enqueue packet#2. > But within SFQ this "failure" might really mean that packet#2 was > accepted to be sent later and it displaced packet#1. It happens that > this "replacement" keeps the packet count correct, but not the byte > count. One can imagine another version of SFQ that, instead of > limiting the number of packets in the queue, limits the number of > bytes. In that case the number of packets would not be correct > either. > > I think that HTB (and other classful qdiscs) should count the > number of bytes and packets "sent" when they're dequeued, not when > they're enqueued. It's an interesting point that, at the moment, I > don't see any way for the classful qdisc to know how many packets and > bytes were dropped. However, I think it would be useful to know > instead how many were passed to enqueue. Then you'd get a report like > Enqueued 32626 bytes 309 pkts, Dequeued 17468 bytes 166 pkts > where the difference is the sum of what's been dropped and what's > still in the queue. > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >
