netdev - Re: tx queue hashing hot-spots and poor performance (multiq, ixgbe)

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]

Message-Id: <20090430.022417.07019547.davem@davemloft.net>
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