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: <20080825.010206.193700650.davem@davemloft.net>
Date:	Mon, 25 Aug 2008 01:02:06 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jarkao2@...il.com
Cc:	hadi@...erus.ca, alexander.duyck@...il.com,
	jeffrey.t.kirsher@...el.com, jeff@...zik.org,
	netdev@...r.kernel.org, alexander.h.duyck@...el.com
Subject: Re: [PATCH 3/3] pkt_sched: restore multiqueue prio scheduler

From: Jarek Poplawski <jarkao2@...il.com>
Date: Mon, 25 Aug 2008 07:57:44 +0000

> On Mon, Aug 25, 2008 at 12:48:25AM -0700, David Miller wrote:
> > From: Jarek Poplawski <jarkao2@...il.com>
> > Date: Mon, 25 Aug 2008 06:06:40 +0000
> > 
> > If we feed packets after the first one to the card, we would not
> > be implementing a FIFO.
> 
> Not necessarilly so: if separate flows are hashed to "their" hwqueues,
> a FIFO per flow would be still obeyed.

What appears on the wire is still going to be similar.

You have to subsequently ask if it's worth the complexity to do
what you seem to be proposing.

When a single hardware queue fills up, it's the SAME, semantically,
as when a unary TX queue of a traditional device fills up.

There is NO on the wire difference.  There will be NO performance
difference, because the device will have work to do as by definition
of one TX queue being full there are some packets queued up to
the device.
--
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