From: Jesper Dangaard Brouer <brouer@redhat.com>
To: "Maciej Żenczykowski" <zenczykowski@gmail.com>
Cc: Linux NetDev <netdev@vger.kernel.org>, Phil Sutter <phil@nwl.cc>,
Robert Olsson <robert@herjulf.se>,
Jamal Hadi Salim <jhs@mojatatu.com>,
brouer@redhat.com
Subject: Re: [net-next PATCH 3/3] qdisc: catch misconfig of attaching qdisc to tx_queue_len zero device
Date: Tue, 8 Nov 2016 08:46:35 +0100 [thread overview]
Message-ID: <20161108084635.02cdc293@redhat.com> (raw)
In-Reply-To: <CAHo-Oozk1AqqR4+9HxLYSGQOQ8Ohs0NaOx=ZV+94JCH-ftxtMw@mail.gmail.com>
On Mon, 7 Nov 2016 22:14:37 -0800 Maciej Żenczykowski <zenczykowski@gmail.com> wrote:
> Just FYI:
>
> I'm tangentially aware of internal Google code that:
> - expects a bonding device running HTB with non-zero txqueuelen
> - wants to remove HTB and get a noqueue interface (the normal default
> for bonding)
>
> The code currently removes HTB, which gets us to mq, sets txqueuelen
> to 0, adds a pfifo, removes the pfifo, which gets us to noqueue.
This clearly shows that the older userspace interface, of tx_queue_len
having double meaning, was a mess!
> After this patch this would ?possibly? break (adding pfifo, would
> change txqueuelen, so when we remove it we wouldn't end up with
> noqueue).
No, you will still end-up with "noqueue". It is now the flag
IFF_NO_QUEUE that determine if a device gets "noqueue" when the default
qdisc is attached. The tx_queue_len no longer have any effect on
getting "noqueue". The IFF_NO_QUEUE system removed this double meaning
of tx_queue_len.
> From what I fuzzily recall, HTB with txquelelen == 0 drops traffic
> hard, while pfifo continues to function, hence the ordering...
>
> Obviously our code can be fixed, but I'm worried there's a more
> generic backwards compatibility problem here.
It is good you bring it up, but I don't see a backwards compatibility
problem with your usage after the patchset.
> (note: this is mostly about 3.11 and 4.3 and might no longer be
> relevant with 4.10... maybe the new kernel's default qdisc selection
> logic doesn't depend on txqueuelen and checks the flag instead???)
If I were you, I would now implement a validation check that reported
the problem if not getting into the expected "noqueue" state. Then
when you eventually upgrade to a more recent kernel, you would get
alerted of improper state.
Something like:
noqueue=$(ip link show dev $DEV 2> /dev/null | grep -q "noqueue" && echo "noqueue" || echo "bad")
if [[ "$noqueue" != "noqueue" ]]; then
echo "report-problem";
fi
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2016-11-08 7:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-03 13:55 [net-next PATCH 0/3] qdisc and tx_queue_len cleanups for IFF_NO_QUEUE devices Jesper Dangaard Brouer
2016-11-03 13:56 ` [net-next PATCH 1/3] net: make default TX queue length a defined constant Jesper Dangaard Brouer
2016-11-03 13:56 ` [net-next PATCH 2/3] net/qdisc: IFF_NO_QUEUE drivers should use consistent TX queue len Jesper Dangaard Brouer
2016-11-03 20:54 ` Krister Johansen
2016-11-04 10:56 ` Jesper Dangaard Brouer
2016-11-03 13:56 ` [net-next PATCH 3/3] qdisc: catch misconfig of attaching qdisc to tx_queue_len zero device Jesper Dangaard Brouer
2016-11-04 9:35 ` Phil Sutter
2016-11-04 10:10 ` Jesper Dangaard Brouer
2016-11-04 10:59 ` Phil Sutter
2016-11-04 12:09 ` Jesper Dangaard Brouer
2016-11-04 12:53 ` Sergei Shtylyov
2016-11-08 6:14 ` Maciej Żenczykowski
2016-11-08 7:46 ` Jesper Dangaard Brouer [this message]
2016-11-07 18:13 ` [net-next PATCH 0/3] qdisc and tx_queue_len cleanups for IFF_NO_QUEUE devices David Miller
2016-11-07 20:11 ` Jesper Dangaard Brouer
2016-11-08 1:16 ` 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=20161108084635.02cdc293@redhat.com \
--to=brouer@redhat.com \
--cc=jhs@mojatatu.com \
--cc=netdev@vger.kernel.org \
--cc=phil@nwl.cc \
--cc=robert@herjulf.se \
--cc=zenczykowski@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.