netdev - Re: [git patches] net driver updates for .28

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 for Android: free password hash cracker in your pocket

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

Message-ID: <48D4A618.5080403@myri.com>
Date:	Sat, 20 Sep 2008 09:28:24 +0200
From:	Brice Goglin <brice@...i.com>
To:	David Miller <davem@...emloft.net>
CC:	jeff@...zik.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [git patches] net driver updates for .28

David Miller wrote:
> No, that is crap.  I didn't create the ->select_tx_queue() callback so
> that each and every damn multiqueue driver will override the generic
> TX hash function in order to try and make the TX hashing match the RX
> hashing.
>
> That's not what it's for.
>
> The callback exists for things like wireless where the queues have
> a meaning other than flow seperation.
>
> We (specifically Herbert Xu and myself) know that for routing and
> firewalling applications matching the TX queue to the same hashing
> namespace of the RX multiqueueing is desirable for best performance.
>
> But we will do that generically by allowing the driver on the receive
> side to record the RX hash used (or alternatively, if the exact RSS
> hash isn't obtainable, the RX queue index itself) and on TX we will
> use this information to select the TX queue properly.
>   

Ok, I'll resend without the select_queue stuff. But you should really
document the above explanation. The only documentation we found was
"Devices or device layers can set this to control the queue selection
performed by dev_pick_tx()." in the git-log...

Brice

--
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