On Thu, 7 Feb 2013 10:51:02 -0500 Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On Feb 7, 2013, at 9:51 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > Now that we're allowing more DRC entries, it becomes a lot easier to hit > > problems with XID collisions. In order to mitigate those, calculate the > > crc32 of up to the first 256 bytes of each request coming in and store > > that in the cache entry, along with the total length of the request. > > I'm happy to see a checksummed DRC finally become reality for the Linux NFS server. > > Have you measured the CPU utilization impact and CPU cache footprint of performing a CRC computation for every incoming RPC? I'm wondering if a simpler checksum might be just as useful but less costly to compute. > No, I haven't, at least not in any sort of rigorous way. It's pretty negligible on "normal" PC hardware, but I think most intel and amd cpus have instructions for handling crc32. I'm ok with a different checksum, we don't need anything cryptographically secure here. I simply chose crc32 since it has an easily available API, and I figured it would be fairly lightweight. I originally had hopes of just using the checksum in the TCP/UDP header, but that's handled in hw by some cards and so isn't available. There are also things that change during a retransmit (like GSS sequence numbers), so we can't just scrape those out anyway. As far as why 256 bytes, we had had a bug opened a while back (by Oracle, I think), that asked us to add this capability and suggested 200 bytes. I like powers of 2 so I rounded up. We could easily extend that though by just changing RC_CSUMLEN if we think it's not enough. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
