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] [day] [month] [year] [list]

Message-ID: <4D9C9D5A.4030500@intel.com>
Date:	Wed, 06 Apr 2011 10:05:30 -0700
From:	Alexander Duyck <alexander.h.duyck@...el.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	"Brattain, Ross B" <ross.b.brattain@...el.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [RFC] ixgbe: is DCA really that good ?

On 4/6/2011 6:44 AM, Eric Dumazet 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 should be a knob (ethtool ?) that an admin can switch off and on,
> port by port, not a CONFIG_IXGBE_DCA thing.
>
> Thanks

The problem is the implementation essentially makes it so that DCA is 
controlled by the availability of the DCA providers.  What would 
probably be the best solution would be for the DCA provider to have a 
means of shutting down specific devices.

The quick and dirty way to disable DCA is to rmmod the ioatdma module 
from the system.  With that removed it will remove the DCA provider and 
essentially turn off DCA.

Thanks,

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