netdev - Re: [RFC] ixgbe: is DCA really that good ?

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]

Date:	Wed, 06 Apr 2011 18:14:22 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Tom Herbert <therbert@...gle.com>
Cc:	Alexander Duyck <alexander.h.duyck@...el.com>,
	Brattain <ross.b.brattain@...el.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [RFC] ixgbe: is DCA really that good ?

Le mercredi 06 avril 2011 à 08:24 -0700, Tom Herbert a écrit :
> On Wed, Apr 6, 2011 at 6:44 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> > Hi guys
> >
> >
> > In a forwarding [or RPS/RFS] setup, why should we populate cpu caches
> > with full frames content ? We only need first cache line to perform
> > routing [or RPS/RFS] decision.
> >
> DCA + accelerated RFS might make good.  But I agree that it should be
> configurable.

An IRQ affinity mismatch is fatal with dca-core current code, because

dca3_get_tag() ->
	dca_common_get_tag() ->
		spin_lock_irqsave(&dca_lock, flags);

Wei Gu hit this on a 64 cpus machine (but only 8 cpus servicing ixgbe
interrupts), and finding the problem took lot of time.



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