netdev - [PATCH 0/14]: Make packet scheduler multiqueue aware.

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-next>] [day] [month] [year] [list]

Message-Id: <20080714.155908.174564017.davem@davemloft.net>
Date:	Mon, 14 Jul 2008 15:59:08 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	netdev@...r.kernel.org
Subject: [PATCH 0/14]: Make packet scheduler multiqueue aware.

Ok, here are the fruits of my weekend in a nutshell, it's
pushed into the net-tx-2.6 tree:

1) Every configuration operation previded by qdiscs and
   classifiers is split into two or three operations:

   Either:

		->validate_foo()
		->commit_foo()
		->cancel_foo()

   Or just:

		->validate_foo()
		->commit_foo()

   The deciding factor is whether validate_foo() allocates
   some resources which need to be liberated if we decide to
   no perform the commit operation.

2) The generic top-level operation code allocates an array
   of info blobs that record the progress of things.

3) First, we iterate over all queues and validate the operation.

4) If all validations pass, we iterate and commit the operation.

5) Else, we iterate and cancel the operation if necessary.

As you can see, this required surgery to a lot of the
packet scheduler layer.  I'm sure I got something wrong,
but conceptually I think everything is sound.

At this point I've tested basic qdisc changes.  For example
on my workstation I'm using a PRIO with 3 bands pointing to
various SFQ and TBF qdiscs.

So I haven't given the filter/classifier stuff much of a good
testing yet.

My next plans are:

1) Integrate the feedback received over the weekend which I
   didn't have time to process yet.

2) Respin the tree against a fresh net-next-2.6

3) Implement "QUEUE_NUM" netlink attribute so that the user can
   request that packet scheduler operations apply to a specific
   queue only.

I think, frankly, this is ready to merge upstream even in it's current
state.  We'll have 3 months to test things more thoroughly and sort
out any thinkos I added to the code.
--
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