From: Phil Sutter <phil@nwl.cc>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org, brouer@redhat.com, davem@davemloft.net
Subject: Re: [PATCH 20/21] net: warn if drivers set tx_queue_len = 0
Date: Wed, 19 Aug 2015 20:39:24 +0200 [thread overview]
Message-ID: <20150819183924.GA12537@orbit.nwl.cc> (raw)
In-Reply-To: <1439909248.6443.19.camel@edumazet-glaptop2.roam.corp.google.com>
Hi,
On Tue, Aug 18, 2015 at 07:47:28AM -0700, Eric Dumazet wrote:
> On Tue, 2015-08-18 at 10:30 +0200, Phil Sutter wrote:
> > Due to the introduction of IFF_NO_QUEUE, there is a better way for
> > drivers to indicate that no qdisc should be attached by default. Though,
> > the old convention can't be dropped since ignoring that setting would
> > break drivers still using it. Instead, add a warning so out-of-tree
> > driver maintainers get a chance to adjust their code before we finally
> > get rid of any special handling of tx_queue_len == 0.
>
> How an admin can remove qdisc on a regular ethernet device with this
> schem ?
>
> I was doing :
>
> tc qdisc replace dev eth0 root pfifo
> ifconfig eth0 txqueuelen 0
> tc qdisc del dev eth0 root
I have a hack wich exports the noqueue qdisc like any other standard
one, so it can be attached to a device. Semantics is a bit odd, though:
| # tc qd show dev eth0
| qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
| # tc qd add dev eth0 root pfifo
| # tc qd show dev eth0
| qdisc pfifo 8003: root refcnt 2 limit 1000p
| # tc qd del dev eth0 root
| # tc qd show dev eth0
| qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
| # tc qd add dev eth0 root noqueue
| # tc qd show dev eth0
| # tc qd del dev eth0 root
| RTNETLINK answers: No such file or directory
So whenn I "add" the noqueue qdisc, it actually leads to no qdisc
attached, and none can be removed afterwards. To recover from this
situation, I have to temporarily attach a different qdisc:
| # tc qd add dev eth0 root pfifo
| # tc qd show dev eth0
| qdisc pfifo 8005: root refcnt 2 limit 1000p
| # tc qd del dev eth0 root
| # tc qd show dev eth0
| qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
This was the quick'n'dirty approach, and I am not satisfied with the
outcome. Instead, I would suggest to have the following:
- noqueue is really the "no queue" like it says, so 'tc qd del root'
attaches noqueue, no matter if virtual or physical interface
- physical interfaces get pfifo_fast by default, which can be removed to
get noqueue
This has a few implications:
- the "default" qdisc (pfifo_fast or noqueue) becomes the "initial"
qdisc
- pfifo_fast needs to be exported, so users can go back to the "initial"
qdisc of physical devices after having removed it
I'll start implementing the above immediately, but would appreciate to
hear your comments on it meanwhile. I wonder especially what makes the
difference between pfifo and pfifo_fast and why the latter can't be
selected explicitly by a user yet. Are there any good reasons for it
aside from it being the "default" and therefore selecting it can be done
by having tx_queue_len > 0 and removing the root qdisc?
Thanks, Phil
next prev parent reply other threads:[~2015-08-19 18:39 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-18 8:30 [PATCH 00/21] net: Convert drivers to IFF_NO_QUEUE and cleanup afterwards Phil Sutter
2015-08-18 8:30 ` [PATCH 01/21] net: veth: enable noqueue operation by default Phil Sutter
2015-08-18 8:30 ` [PATCH 02/21] net: dummy: convert to using IFF_NO_QUEUE Phil Sutter
2015-08-18 8:30 ` [PATCH 03/21] net: geneve: " Phil Sutter
2015-08-18 8:30 ` [PATCH 04/21] net: loopback: " Phil Sutter
2015-08-18 8:30 ` [PATCH 05/21] net: nlmon: " Phil Sutter
2015-08-18 8:30 ` [PATCH 06/21] net: team: " Phil Sutter
2015-08-18 8:30 ` [PATCH 07/21] net: vxlan: " Phil Sutter
2015-08-18 8:30 ` [PATCH 08/21] net: 8021q: " Phil Sutter
2015-08-18 8:30 ` [PATCH 09/21] net: bridge: " Phil Sutter
2015-08-18 8:30 ` [PATCH 10/21] net: 6lowpan: " Phil Sutter
2015-08-18 8:30 ` [PATCH 11/21] net: bonding: " Phil Sutter
2015-08-18 8:30 ` [PATCH 12/21] net: ipvlan: " Phil Sutter
2015-08-18 8:30 ` [PATCH 13/21] net: dsa: " Phil Sutter
2015-08-18 8:30 ` [PATCH 14/21] net: hostap: " Phil Sutter
2015-08-18 8:30 ` [PATCH 15/21] net: mac80211_hwsim: " Phil Sutter
2015-08-18 8:30 ` [PATCH 16/21] net: batman-adv: " Phil Sutter
2015-08-18 8:30 ` [PATCH 17/21] net: hsr: " Phil Sutter
2015-08-18 8:30 ` [PATCH 18/21] net: caif: " Phil Sutter
2015-08-18 8:30 ` [PATCH 19/21] staging: wilc1000: " Phil Sutter
2015-08-18 8:30 ` [PATCH 20/21] net: warn if drivers set tx_queue_len = 0 Phil Sutter
2015-08-18 8:30 ` [PATCH 21/21] net: sched: drop all special handling of tx_queue_len == 0 Phil Sutter
2015-08-18 14:47 ` [PATCH 20/21] net: warn if drivers set tx_queue_len = 0 Eric Dumazet
2015-08-18 18:14 ` Phil Sutter
2015-08-19 18:39 ` Phil Sutter [this message]
2015-08-19 20:21 ` Phil Sutter
2015-08-19 20:31 ` Eric Dumazet
2015-08-19 20:33 ` Eric Dumazet
2015-08-19 21:04 ` Phil Sutter
2015-08-18 8:43 ` [PATCH 15/21] net: mac80211_hwsim: convert to using IFF_NO_QUEUE Johannes Berg
2015-08-18 18:54 ` David Miller
2015-08-18 18:56 ` [PATCH 00/21] net: Convert drivers to IFF_NO_QUEUE and cleanup afterwards David Miller
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=20150819183924.GA12537@orbit.nwl.cc \
--to=phil@nwl.cc \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
/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).