netdev - RE: [PATCH] NET: Multiqueue network device support.

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]

Date:	Mon, 11 Jun 2007 11:15:32 -0700
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	"Patrick McHardy" <kaber@...sh.net>
Cc:	<davem@...emloft.net>, <netdev@...r.kernel.org>, <jeff@...zik.org>,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>
Subject: RE: [PATCH] NET: Multiqueue network device support.

> I think grepping will help more than testing :)
> 
> The only issue I can see is that packets going to a 
> multiqueue device that doesn't have a multiqueue aware qdisc 
> attached will get a random value. So you would have to 
> conditionally reset it before ->enqueue.

I currently clear queue_mapping before ->enqueue().  Perhaps keeping
queue_mapping in there might solve needing a conditional in the hotpath.
Let me think about this one.

> Another question is what to do about other hard_start_xmit callers.
> Independant of which field is used, should the classification 
> that may have happend on a different device be retained (TC 
> actions again)?

The two cases I can think of here are ip forwarding and bonding.  In the
case of bonding, things should be fine since the bonded device will only
have one "ring."  Therefore if the underlying slave devices are
heterogenous, there shouldn't be a problem retaining the previous TC
classification; if the device has its own qdisc and classifiers, it can
override it.

For ip forwarding, I believe it will also be ok since ultimately the
device doing the last transmit will have his classifiers applied and
remap skb's if necessary.  Either way, before it gets enqueued through
dev_queue_xmit(), the value will get cleared, so having an artifact
laying around won't be possible.

If that's not what you're referring to, please let me know.

Thanks,
-PJ Waskiewicz
-
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