From: Stephen Hemminger <shemminger@vyatta.com>
To: Patrick McHardy <kaber@trash.net>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH] netdev: handle setting transmit queue length on active device.
Date: Wed, 18 Mar 2009 11:16:05 -0700 [thread overview]
Message-ID: <20090318111605.06ed6548@nehalam> (raw)
In-Reply-To: <49C13887.2070801@trash.net>
On Wed, 18 Mar 2009 19:08:07 +0100
Patrick McHardy <kaber@trash.net> wrote:
> Stephen Hemminger wrote:
> > On Wed, 18 Mar 2009 18:15:38 +0100
> > Patrick McHardy <kaber@trash.net> wrote:
> >
> >> Stephen Hemminger wrote:
> >>> Some virtual devices like VLAN's or bridges by default have not transmit queue.
> >>> In order to do queuing disciplines on these devices a queue must be added
> >>> by setting transmit queue length. The kernel allows doing this at any time, but
> >>> setting the queue length value is not enough. Setting the queue length does
> >>> not create the transmit queue (going from 0 to non-zero) or destroy it
> >>> (setting to zero); the queue is only created (or destroyed) when device
> >>> comes up (or goes down).
> >>>
> >>> This patch handles this be doing the necessary activations.
> >>>
> >> That seems quite heavy-weight in case of hierarchical qdiscs, it will
> >> walk and reset the entire tree and looses all state, including packets
> >> as a side effect. Its also a bit inconsistent since it only affects
> >> the default pfifos at the root, not the inner default qdiscs if I'm
> >> not mistaken.
> >>
> >> A less intrusive way would be to simply use dev->tx_queue_len directly
> >> in pfifo when no limit is configured. That would require to make a
> >> runtime decision for each packet though. Two more alternatives:
> >>
> >> - add a special pfifo variant that always uses tx_queue_len. Duplication
> >> comes down to pfifo_enqueue (a few lines) and a new struct Qdisc_ops
> >>
> >> - if you really only care about the root, reconfigure it explicitly
> >> using fifo_set_limit()
> >>
> >
> > The problem is when setting limit to 0 to force noop and setting it
> > to non-zero to force pfifo_fast back again.
>
>
> I'd suggest to simply attach a pfifo qdisc with an explicitly
> configured limit to activate queueing on virtual devices.
The existing code is broken if user does:
# ip li set dev eth0.200 txq 200
# tc qdisc set dev eth0.200 root sfq
# tc qdisc del dev eth0.200 root
# ip li set dev eth0.200 txq 0
The vlan is now dead because it is impossible to go back
to the no queueing (noop) qdisc. Also, when doing performance tests
it is useful to be able to turn off transmit queue entirely.
Other alternative would be to reject changes to txq when device is
up, but that probably would break existing users. And would be a pain
in the ass when trying to configure PPP and tunnel endpoints.
next prev parent reply other threads:[~2009-03-18 18:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-18 17:02 [PATCH] netdev: handle setting transmit queue length on active device Stephen Hemminger
2009-03-18 17:15 ` Patrick McHardy
2009-03-18 18:02 ` Stephen Hemminger
2009-03-18 18:08 ` Patrick McHardy
2009-03-18 18:16 ` Stephen Hemminger [this message]
2009-03-18 18:31 ` Patrick McHardy
2009-03-18 18:20 ` Stephen Hemminger
2009-03-18 17:18 ` Eric Dumazet
2009-03-18 18:00 ` Stephen Hemminger
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=20090318111605.06ed6548@nehalam \
--to=shemminger@vyatta.com \
--cc=davem@davemloft.net \
--cc=kaber@trash.net \
--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).