This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] remus: fix check for installed qdiscs on ifb

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] remus: fix check for installed qdiscs on ifb
From: Shriram Rajagopalan <rshriram@xxxxxxxxx>
Date: Mon, 21 Mar 2011 10:56:29 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 21 Mar 2011 10:59:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19847.26121.779498.471147@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <87f94f4f06c4403b97c4.1300592390@xxxxxxxxxxxxxxxxxxx> <19847.26121.779498.471147@xxxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: rshriram@xxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Mon, Mar 21, 2011 at 7:51 AM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
Shriram Rajagopalan writes ("[Xen-devel] [PATCH] remus: fix check for installed qdiscs on ifb"):
> remus: fix check for installed qdiscs on ifb


> current check includes ingress and pfifo_fast.
> Add mq to the list of allowed qdiscs already installed
> on ifb. This patch fixes cases where remus fails to start,
> due to an mq qdisc already present on the vif.

Forgive me for being dense, but I don't understand this at all.  What
is the problem caused by pre-existing qdiscs that the code is trying
to avoid, and why are these particular qdiscs OK ?

sorry. my bad. It is not the pre-existing qdiscs that cause an issue. It is
caused by the dummy "mq" qdisc that gets added by "default". The original
code checks for presence of only ingress/pfifo-fast qdisc. If anything else is
present, it punts. In this case, "mq" is present (added by default) and causes
remus to fail.

This is what I understood from the kernel netfilter code & docs.

from net/netfilter/sched/sched_generic.c
void dev_activate(struct net_device *dev)
        /* No queueing discipline is attached to device;
           create default one i.e. pfifo_fast for devices,
           which need queueing and noqueue_qdisc for
           virtual interfaces

        if (dev->qdisc == &noop_qdisc)
static void attach_default_qdiscs(struct net_device *dev)
        if (!netif_is_multiqueue(dev) || dev->tx_queue_len == 0) {
                netdev_for_each_tx_queue(dev, attach_one_default_qdisc, NULL);
        } else {
                qdisc = qdisc_create_dflt(dev, txq, &mq_qdisc_ops, TC_H_ROOT);

sch_mq is a "Classful multiqueue dummy scheduler" and according to the
multiqueue semantics in Section 2: Documentation/networking/multiqueue.txt

"Currently two qdiscs are optimized for multiqueue devices.  The first is the
default pfifo_fast qdisc.  This qdisc supports one qdisc per hardware queue.
A new round-robin qdisc, sch_multiq also supports multiple hardware queues."


Xen-devel mailing list