linux-kernel - RE: [PATCH v6 00/10] crc32

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: <01c001cc6cae$60a95080$21fbf180$@systemfabricworks.com>
Date:	Tue, 6 Sep 2011 11:02:27 -0500
From:	"Bob Pearson" <rpearson@...temfabricworks.com>
To:	"'Andrew Morton'" <akpm@...ux-foundation.org>
Cc:	<linux-kernel@...r.kernel.org>, <fzago@...temfabricworks.com>,
	"'Joakim Tjernlund'" <joakim.tjernlund@...nsmode.se>,
	"'George Spelvin'" <linux@...izon.com>
Subject: RE: [PATCH v6 00/10] crc32

I took the holiday weekend off so this is somewhat delayed.

> -----Original Message-----
> From: Andrew Morton [mailto:akpm@...ux-foundation.org]
> Sent: Friday, September 02, 2011 6:50 PM
> To: Bob Pearson
> Cc: linux-kernel@...r.kernel.org; fzago@...temfabricworks.com; Joakim
> Tjernlund; George Spelvin
> Subject: Re: [PATCH v6 00/10] crc32
> 
> On Wed, 31 Aug 2011 17:29:32 -0500
> Bob Pearson <rpearson@...temfabricworks.com> wrote:
> 
> > This is an attempt to resolve all the issues that were left in the last
review.
> > There is one proposed change that is still causing a difference of
opinion
> > which has to do with the form of the loops and their performance on x86
> and ppc
> > This version has the change to the form that runs faster on x86 as an
ifdef.
> >
> > This patch series provides improved performance for computing the crc32
> > polynomial on common hardware by adding the Slicing-by-8 algorithm to
> the
> > existing algorithms already included. The new algorithm is very closely
> > related to the existing algorithm so the extension requires small
changes
> > to implement.  Additionally it cleans up some warnings in the existing
> > code and adds a kernel mode optional self test to replace the existing
> > user mode self test.
> >
> > A description of the existing and new algorithm is included in
> > Documentation/crc32.txt.
> 
> So...  are the crc wars over yet?  I hope it's safe to look at the
> patches now ;)

I hope so.

> 
> Please see Documentation/SubmittingPatches Section 15's discussion of
> patch Subject: lines.

Which sin am I committing? Use of 'vn' seems widespread but is not
specifically mentioned in the document. I am not sure about whether crc32
rises to the level of a 'subsystem' but chose that label. I am missing a
colon though.

> 
> Is there any code in the kernel which uses the crc code so much that we
> actually care about its performance?

I can only speak for myself. I am working on a project to write a software
emulation of an RDMA (InfiniBand like) protocol called RoCE or RDMA over
Converged Ethernet. This protocol uses CRC32 as an L3 CRC that is carried
end to end. Without this change to CRC32 the best performance on a single
core was well below 1GB/src. With it, performance is closer to the wire
speed of hardware implementations, i.e. around 1GB/sec.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/