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 PHC | |
Open Source and information security mailing list archives
| ||
|
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
Powered by blists - more mailing lists