From: Jesper Dangaard Brouer <brouer@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: phil@nwl.cc, fw@strlen.de, netdev@vger.kernel.org,
cwang@twopensource.com, eric.dumazet@gmail.com,
brouer@redhat.com
Subject: Re: [net-next PATCH 1/3] net: make default tx_queue_len configurable
Date: Tue, 11 Aug 2015 17:48:07 +0200 [thread overview]
Message-ID: <20150811174807.3e00b4da@redhat.com> (raw)
In-Reply-To: <20150729.143731.834219016906219771.davem@davemloft.net>
On Wed, 29 Jul 2015 14:37:31 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
[...]
> Which is that there are devices (virtual or whatever) which don't want
> a qdisc attached no matter what. Flag those devices as such and
> adjust the qdisc attachment logic to check that new flag.
I agree on the approach DaveM are suggesting.
But virtual devices must support getting a qdisc attached. I know of
many companies depending on this behavior. Some times people just get
hit by this "strange" zero len issues when they happen to use
pfifo_fast as leaf node.
> Anything is better than hacking the queue len.
The hole problem comes from the double meaning of the queue len. e.g.
that value 0 have special meaning, but only during assigning the
default qdisc. And pfifo_fast will use queue len zero if assigned.
(proposed solution:)
As DaveM also suggested, I would likely use a device flag to indicate
the device does not require any qdisc, and not assign any qdisc
(actually "noqueue") in case the default qdisc is chosen for this
device.
This should solve the problem for veth. And then we should cleanup all
the virtual devices, adding this flag and changing the
dev->tx_queue_len to the default value (e.g. remove setting it to zero).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2015-08-11 15:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-29 20:51 [net-next PATCH 0/3] Backwards-compatible noqueue in virtual interfaces Phil Sutter
2015-07-29 20:51 ` [net-next PATCH 1/3] net: make default tx_queue_len configurable Phil Sutter
2015-07-29 20:51 ` [net-next PATCH 2/3] net: sched: set tx_queue_len to default when changing noqueue device's qdisc Phil Sutter
2015-07-29 20:51 ` [net-next PATCH 3/3] veth: don't assign a qdisc to veth Phil Sutter
2015-07-29 21:10 ` [net-next PATCH 2/3] net: sched: set tx_queue_len to default when changing noqueue device's qdisc Florian Westphal
2015-07-29 21:10 ` Eric Dumazet
2015-07-29 22:08 ` Phil Sutter
2015-07-29 21:06 ` [net-next PATCH 1/3] net: make default tx_queue_len configurable Florian Westphal
2015-07-29 21:34 ` Phil Sutter
2015-07-29 21:37 ` David Miller
2015-08-11 15:48 ` Jesper Dangaard Brouer [this message]
2015-08-11 16:23 ` Phil Sutter
2015-08-12 1:13 ` Alexei Starovoitov
2015-08-12 14:55 ` Eric Dumazet
2015-08-13 1:13 ` Phil Sutter
2015-08-13 13:10 ` Jesper Dangaard Brouer
2015-08-13 15:06 ` Phil Sutter
2015-07-29 23:10 ` [net-next PATCH 0/3] Backwards-compatible noqueue in virtual interfaces Cong Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150811174807.3e00b4da@redhat.com \
--to=brouer@redhat.com \
--cc=cwang@twopensource.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=fw@strlen.de \
--cc=netdev@vger.kernel.org \
--cc=phil@nwl.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).