Searched hist:"1 f27cde313d72d6b44a73ba89c8b2c6a99c628cf" (Results 1 – 4 of 4) sorted by relevance
/openbmc/linux/net/sched/ |
H A D | sch_mq.c | diff 1f27cde313d72d6b44a73ba89c8b2c6a99c628cf Wed Mar 02 10:21:43 CST 2016 Eric Dumazet <edumazet@google.com> net: sched: use pfifo_fast for non real queues
Some devices declare a high number of TX queues, then set a much lower real_num_tx_queues
This cause setups using fq_codel, sfq or fq as the default qdisc to consume more memory than really needed.
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
H A D | sch_mqprio.c | diff 1f27cde313d72d6b44a73ba89c8b2c6a99c628cf Wed Mar 02 10:21:43 CST 2016 Eric Dumazet <edumazet@google.com> net: sched: use pfifo_fast for non real queues
Some devices declare a high number of TX queues, then set a much lower real_num_tx_queues
This cause setups using fq_codel, sfq or fq as the default qdisc to consume more memory than really needed.
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
H A D | sch_generic.c | diff 1f27cde313d72d6b44a73ba89c8b2c6a99c628cf Wed Mar 02 10:21:43 CST 2016 Eric Dumazet <edumazet@google.com> net: sched: use pfifo_fast for non real queues
Some devices declare a high number of TX queues, then set a much lower real_num_tx_queues
This cause setups using fq_codel, sfq or fq as the default qdisc to consume more memory than really needed.
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
/openbmc/linux/include/net/ |
H A D | sch_generic.h | diff 1f27cde313d72d6b44a73ba89c8b2c6a99c628cf Wed Mar 02 10:21:43 CST 2016 Eric Dumazet <edumazet@google.com> net: sched: use pfifo_fast for non real queues
Some devices declare a high number of TX queues, then set a much lower real_num_tx_queues
This cause setups using fq_codel, sfq or fq as the default qdisc to consume more memory than really needed.
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|