On 11:35, Dan Williams wrote: > > Don't we need to fall back to sync xor if src_cnt exceeds > > what the device can handle, i.e. if it is larger than > > chan->device->max_xor? async_xor_val() further down has a check for > > this condition. > > No, we don't need this check for async_xor(). The asynchronous path > of async_xor_val() has the constraint that it must be able to validate > an xor block without writing to that block i.e. it is a read-only > operation. The synchronous path recalculates the xor with the > destination as a source and then does a memcmp() to validate that the > new result is zero. > > To support more than ->max_xor sources for async_xor_val() we would > need an engine that supported hardware continuation of validate > operations (i.e. an engine with an internal buffer for the > intermediate xor result) otherwise we will need to store an > intermediate xor result in system memory which is no better than the > synchronous path. > > For async_xor() we are always allowed to write the destination, so we > can reuse it as a source to continue the calculation of the xor > result. I see. Thanks for this detailed explanation! BTW: So far I've only glanced at patches 7-11 of your series. I will review these patches this evening and tomorrow, so I'll send another batch of comments/questions/sign-offs by Friday. Robinson^WAndre -- The only person who always got his work done by Friday was Robinson Crusoe
Attachment:
signature.asc
Description: Digital signature
