netdev - Re: [PATCH 3/3] pkt_sched: restore multiqueue prio scheduler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080822.031654.29257013.davem@davemloft.net>
Date:	Fri, 22 Aug 2008 03:16:54 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jeffrey.t.kirsher@...el.com
Cc:	jeff@...zik.org, netdev@...r.kernel.org,
	alexander.h.duyck@...el.com
Subject: Re: [PATCH 3/3] pkt_sched: restore multiqueue prio scheduler

From: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Date: Thu, 21 Aug 2008 17:51:29 -0700

> From: Alexander Duyck <alexander.h.duyck@...el.com>
> 
> This patch restores the multiqueue prio scheduler which was removed along with
> the RR scheduler during the early changes for multiple tx queue support.  This
> patch fixes the regression which occured as a result disabling the multiqueue
> qdisc functionality.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@...el.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>

So how in the world would you use this?

If it's just to tag traffic into different TX queues by priority,
that's not very wise nor desirable.  What's the point?

The TX queues are useful for multiplexing traffic and seperating
the locking and cpu overhead across execution entities in the
system.  They can also be useful for virtualization, but that's
not relevant in this discussion.

The TX queues, on the other hand, are not useful for exposing the
round-robin or whatever algorithm that some cards just so happen to
enforce fairness amongst the TX queues.  That's an implementation
detail.

The truth is, the only reason the RR prio scheduler got added was
because Jamal and myself didn't understand very well how to use these
multiqueue cards, or at least I didn't understand it.

And therefore we, at the time, recommended to implement the RR prio
thing even though now I realize it's totally the wrong thing to do
for TX multiqueue stuff.

I removed this code very much intentionally, and it's only going to go
back if I hear a very good argument for doing so.  And "taking it away
is a regression" is not what I'm looking for, give me something better
than that :)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html