Date: Sun, 6 Dec 2015 12:07:22 -0500 From: Thor Lancelot Simon <[email protected]>
On Sun, Dec 06, 2015 at 04:01:22PM +0000, Taylor R Campbell wrote: > > Aside: This is probably because ipintr gets scheduled on a specified > target CPU, not on the local CPU, in pktq_enqueue...and apparently > every caller, except for bridges, specifies CPU 0. Huh. This is either a concurrency-limiting bug in all the other code, or a problem with the bridge code. Which do you think it is? It is a provisional limitation until softnet_lock goes away or is no longer a bottleneck. See the comment in sys/net/pktqueue.c in pktq_rps_hash, which `hashes' an mbuf to determine the CPU index. (Many callers also explicitly pass 0 for the hash/index. Why only ether_input calls pktq_rps_hash, I don't know -- rmind?)
