| 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
| ||
|
Message-ID: <g2l65634d661004021059z94214a43v82409d15a0fb09b6@mail.gmail.com> Date: Fri, 2 Apr 2010 10:59:43 -0700 From: Tom Herbert <therbert@...gle.com> To: Stephen Hemminger <shemminger@...tta.com> Cc: Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org Subject: Re: Receive steering and hash and cache misses On Fri, Apr 2, 2010 at 10:26 AM, Stephen Hemminger <shemminger@...tta.com> wrote: > > Although Receive Packet Steering can use a hardware generated receive hash > the device driver still causes an unnecessary cache miss on the interrupt > processing CPU. The current Ethernet network device driver receive processing > has the device driver calling eth_type_trans() which causes a the > interrupt CPU to read the received frame header. > It should be possible to deduce the values set by eth_type_trans from the RX descriptor along with the RX hash. I'll post the patch getting rxhash from bnx2x which does this. > Is there some way the hardware receive hash value could be used to > steer to the receive CPU, then have the receive CPU find the Ethernet > type field (eth_type_trans)? > -- > 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 -- 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