| 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
| ||
|
Date: Thu, 30 Apr 2009 02:24:17 -0700 (PDT) From: David Miller <davem@...emloft.net> To: jelaas@...il.com Cc: andrew@...dna.net, netdev@...r.kernel.org Subject: Re: tx queue hashing hot-spots and poor performance (multiq, ixgbe) From: Jens Låås <jelaas@...il.com> Date: Thu, 30 Apr 2009 11:07:35 +0200 > RX-side looks good. TX-side looks like what we also got with vanilla linux. > > What we do is patch all drivers with a custom select_queue function > that selects the same outgoing queue as the incoming queue. With a one > to one mapping of queues to CPUs you can also use the processor id. > > This way we get performance. I don't understand why this can even be necessary. With the current code, the RX queue of a packet becomes the hash for the TX queue. If all the TX activity is happening on one TX queue then there is a bug somewhere. Either the receiving device isn't invoking skb_record_rx_queue() correctly, or there is some bug in how we compute the TX hash. Everyone adds their own hacks, but that absolutely should not be necessary, the kernel is essentially doing what you are adding hacks for. The only possible problems are bugs in the code, and we should find those bugs instead of constantly talking about 'local select_queue hacks we add to our cool driver for performance' :-/ -- 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