On Wed, Nov 20, 2013 at 2:31 AM, David Brown <david.br...@hesbynett.no> wrote: > That's certainly a reasonable way to look at it. We should not limit > the possibilities for high-end systems because of the limitations of > low-end systems that are unlikely to use 3+ parity anyway. I've also > looked up a list of the processors that support SSE3 and PSHUFB - a lot > of modern "low-end" x86 cpus support it. And of course it is possible > to implement general G(2^8) multiplication without PSHUFB, using a > lookup table - it is important that this can all work with any CPU, even > if it is slow.
Unfortunately, it is SSSE3 that is required for PSHUFB. The SSE3 set with only two-esses does not suffice. I made that same mistake when I first heard about Andrea's 6-parity work. SSSE3 vs. SSE3, confusing notation! SSSE3 is significantly less widely supported than SSE3. Particularly on AMD, only the very latest CPUs seem to support SSSE3. Intel support for SSSE3 goes back much further than AMD support. Maybe it is not such a big problem, since it may be possible to support two "roads". Both roads would include the current md RAID-5 and RAID-6. But one road, which those lacking CPUs supporting SSSE3 might choose, would continue on to the non-SSSE3 triple-parity 2^-1 technique, and then dead-end. The other road would continue with the Cauchy matrix technique through 3-parity all the way to 6-parity. It might even be feasible to allow someone stuck at the end of the non-SSSE3 road to convert to the Cauchy road. You would have to go through all the 2^-1 triple-parity and convert it to Cauchy triple-parity. But then you would be safely on the Cauchy road. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
