| 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: <BANLkTikyH=q_6uOvFh3_Z_xwPST3zVijZw@mail.gmail.com> Date: Tue, 17 May 2011 13:02:25 -0700 From: Tom Herbert <therbert@...gle.com> To: David Miller <davem@...emloft.net> Cc: netdev@...r.kernel.org Subject: Re: small RPS cache for fragments? I like it! And this sounds like the sort of algorithm that NICs might be able to implement to solve the UDP/RSS unpleasantness, so even better. Tom On Tue, May 17, 2011 at 11:33 AM, David Miller <davem@...emloft.net> wrote: > > It seems to me that we can solve the UDP fragmentation problem for > flow steering very simply by creating a (saddr/daddr/IPID) entry in a > table that maps to the corresponding RPS flow entry. > > When we see the initial frag with the UDP header, we create the > saddr/daddr/IPID mapping, and we tear it down when we hit the > saddr/daddr/IPID mapping and the packet has the IP_MF bit clear. > > We only inspect the saddr/daddr/IPID cache when iph->frag_off is > non-zero. > > It's best effort and should work quite well. > > Even a one-behind cache, per-NAPI instance, would do a lot better than > what happens at the moment. Especially since the IP fragments mostly > arrive as one packet train. > -- > 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