On Thu, 7 Feb 2013 16:32:20 +0000 "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > > -----Original Message----- > > From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs- > > owner@xxxxxxxxxxxxxxx] On Behalf Of J. Bruce Fields > > Sent: Thursday, February 07, 2013 11:01 AM > > To: Chuck Lever > > Cc: Jeff Layton; linux-nfs@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH v3 2/2] nfsd: keep a checksum of the first 256 bytes of > > request > > > > On Thu, Feb 07, 2013 at 10:51:02AM -0500, Chuck Lever 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? > > > > Note this is over the first 256 bytes of the request--which we're probably just > > about to read for xdr decoding anyway. > > - Would it make sense perhaps to generate the checksum as you are reading the data? Maybe, but I'm not sure it's worth the engineering effort. On my highly unscientific test rig, the time to calculate the checksum is ~800ns using the IP checksum routine. If we can run the checksum while we read the data off the socket, then we might shave some of that off, but that "feels" like small potatoes to me. OTOH, I don't have a good way to measure what the effect of this is on the CPU cache. Any ideas of how to measure whether that's significant? > - Also, is 256 bytes sufficient? How far does that get you with your average WRITE compound? I also had a look at this, and it looks like the data portion of a WRITE compound from the Linux client starts at ~80 bytes from the beginning of the NFS part of the frame. So with a 256 byte checksum length, we're checksumming over about 176 bytes of write data from a typical NFSv4.0 WRITE request. It might not hurt to extend that out to 384 bytes or so? We have to figure that some clients also set the tag field, so having a bit of fudge factor for that might be reasonable. Making it variable doesn't seem like it would buy us too much since most calls are much smaller than 256 bytes to begin with. -- 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
