48d83325b6
Having two or more qdisc_run's contend against each other is bad because it can induce packet reordering if the packets have to be requeued. It appears that this is an unintended consequence of relinquinshing the queue lock while transmitting. That in turn is needed for devices that spend a lot of time in their transmit routine. There are no advantages to be had as devices with queues are inherently single-threaded (the loopback device is not but then it doesn't have a queue). Even if you were to add a queue to a parallel virtual device (e.g., bolt a tbf filter in front of an ipip tunnel device), you would still want to process the queue in sequence to ensure that the packets are ordered correctly. The solution here is to steal a bit from net_device to prevent this. BTW, as qdisc_restart is no longer used by anyone as a module inside the kernel (IIRC it used to with netif_wake_queue), I have not exported the new __qdisc_run function. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|---|---|---|
| .. | ||
| Kconfig | ||
| Makefile | ||
| act_api.c | ||
| act_gact.c | ||
| act_ipt.c | ||
| act_mirred.c | ||
| act_pedit.c | ||
| act_police.c | ||
| act_simple.c | ||
| cls_api.c | ||
| cls_basic.c | ||
| cls_fw.c | ||
| cls_route.c | ||
| cls_rsvp.c | ||
| cls_rsvp.h | ||
| cls_rsvp6.c | ||
| cls_tcindex.c | ||
| cls_u32.c | ||
| em_cmp.c | ||
| em_meta.c | ||
| em_nbyte.c | ||
| em_text.c | ||
| em_u32.c | ||
| ematch.c | ||
| estimator.c | ||
| sch_api.c | ||
| sch_atm.c | ||
| sch_blackhole.c | ||
| sch_cbq.c | ||
| sch_dsmark.c | ||
| sch_fifo.c | ||
| sch_generic.c | ||
| sch_gred.c | ||
| sch_hfsc.c | ||
| sch_htb.c | ||
| sch_ingress.c | ||
| sch_netem.c | ||
| sch_prio.c | ||
| sch_red.c | ||
| sch_sfq.c | ||
| sch_tbf.c | ||
| sch_teql.c | ||