This seems to be an error in the Pegasus manual. it will be reported. The dropdown mentioned is available on the E5800 and probably the entire E-class line. But changing the RAID6 codec is not supported on the Pegasus line, even in the CLI.
It is not clear which codec schema is being described by (P+Q) and (Q+Q), but whichever codec, both parity stripes must use the same codec. Generally in the literature P and Q are used to refer to a disk that has failed rather than a codec.
As for reliability, all codec schemas are equally reliable, the difference is in cost of generating and updating the parity information. This is why RAID6 writes are slower than RAID5 writes. In the ancient M500i, it could take a day for a large RAID6 LUN to sync, the processor was challenged by the parity calculation. The workaround was to do a full init, which took only a few hours for the same array. Today the processors are much faster and there is no speed advantage for an init over a sync.
This is a legacy page, but it shows many RAID6 codecs (there may be others today) and discusses their relative merits, And it says this about Reed-Solomon.
- Reed-Solomon Coding [Reed60] is a very powerful general-purpose coding technique. It involves breaking up the data on each device into w-bit words, and then having the i-th word on the Q device be calculated from the i-th word on each data device using a special kind of arithmetic called Galois Field arithmetic (GF(2w)). Galois Field addition is equivalent to the XOR operation; multiplication is much more difficult and requires one of a variety of techniques for implementation. As such, Reed-Solomon Coding is expensive compared to the other techniques. Reed-Solomon Coding is described in every text on coding theory [MacWilliams77,Moon05,Peterson72,vanLint82] and has tutorial instructions written explicitly for storage systems designers [Plank97,Plank05].
The literatue for RAID encoding is rather technical. Expensive in this contect means a lot of CPU resources are needed to parity generation.