* pkt_sched: Fix qdisc len in qdisc_peek_dequeued() [61c9eaf9008] - question
@ 2014-11-16 13:04 Michal Soltys
2014-11-16 18:15 ` Eric Dumazet
0 siblings, 1 reply; 3+ messages in thread
From: Michal Soltys @ 2014-11-16 13:04 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Linux Netdev List
Hi,
I was wondering (probably missing some subtleties) about that particular
patch, namely:
61c9eaf90081cbe6dc4f389e0056bff76eca19ec
Why would that qlen++ change be necessary ? As far as peeked qdisc sees
things, the packet is already deqeued and gone - so not really part of
the queue anymore in this context (not ever requeued either). More
advanced qdiscs such as say fq_codel - if for example they decide to
drop head during further enqueue operation - obviously won't even
consider the peeked packet.
Increasing qlen from what I can see artificially shortens queue by 1.
For some classful schedulers (say like hfsc that instantly peeks next
packet length after dequeuing), child qdiscs will be almost all the time
formally operating at queue size decreased by 1.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: pkt_sched: Fix qdisc len in qdisc_peek_dequeued() [61c9eaf9008] - question
2014-11-16 13:04 pkt_sched: Fix qdisc len in qdisc_peek_dequeued() [61c9eaf9008] - question Michal Soltys
@ 2014-11-16 18:15 ` Eric Dumazet
2014-11-16 21:09 ` Michal Soltys
0 siblings, 1 reply; 3+ messages in thread
From: Eric Dumazet @ 2014-11-16 18:15 UTC (permalink / raw)
To: Michal Soltys; +Cc: Jarek Poplawski, Linux Netdev List
On Sun, 2014-11-16 at 14:04 +0100, Michal Soltys wrote:
> Hi,
>
> I was wondering (probably missing some subtleties) about that particular
> patch, namely:
>
> 61c9eaf90081cbe6dc4f389e0056bff76eca19ec
>
> Why would that qlen++ change be necessary ? As far as peeked qdisc sees
> things, the packet is already deqeued and gone - so not really part of
> the queue anymore in this context (not ever requeued either). More
> advanced qdiscs such as say fq_codel - if for example they decide to
> drop head during further enqueue operation - obviously won't even
> consider the peeked packet.
peeked packet has not to be considered by qdisc : Their dequeue()
methods is called only when there is no more peeked packet.
>
> Increasing qlen from what I can see artificially shortens queue by 1.
> For some classful schedulers (say like hfsc that instantly peeks next
> packet length after dequeuing), child qdiscs will be almost all the time
> formally operating at queue size decreased by 1.
Well, the peeked packet is part of the queue, as it is not yet
transmitted.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-11-16 21:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-16 13:04 pkt_sched: Fix qdisc len in qdisc_peek_dequeued() [61c9eaf9008] - question Michal Soltys
2014-11-16 18:15 ` Eric Dumazet
2014-11-16 21:09 ` Michal Soltys
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).