Re: [PATCH] scatterlist: Speed up for_each_sg() loop macro

[Jason Gunthorpe]

On Mon, Oct 28, 2019 at 09:18:48AM -0700, Sultan Alsawaf wrote:
> On Mon, Oct 28, 2019 at 11:17:34AM -0300, Jason Gunthorpe wrote:
> > This is a big change in the algorithm, why are you sure it is OK?
> 
> I'm sure it's OK because the test module I provided in the commit message
> encapsulates all the possible edge cases of sg chaining:
> -An sglist with >=1 && <=(SG_MAX_SINGLE_ALLOC-1) nents (no chaining, the last
>  element in the array is unused)
> -An sglist with SG_MAX_SINGLE_ALLOC nents (no chaining, the last element in the
>  array isn't an sg chain link)
> -An sglist with >SG_MAX_SINGLE_ALLOC && <=2*(SG_MAX_SINGLE_ALLOC-1) nents (there
>  is one chain to another array, and the other array's last element is unused)
> -An sglist with (2*SG_MAX_SINGLE_ALLOC)-1 nents (there is one chain to another
>  array, and the other array's last element isn't an sg chain link)
> -An sglist with 2*SG_MAX_SINGLE_ALLOC nents (there are two chains to other
>  arrays, and the 3rd array contains 2 sgs & its last element is unused)
> -An sglist with >2*SG_MAX_SINGLE_ALLOC && <(3*SG_MAX_SINGLE_ALLOC)-1 nents
>  (there are two chains to other arrays, and the 3rd array's last element isn't
>  an sg chain)

This testing is making assumptions about how 'nr' is used and the
construction of the sgl though

If any chains are partially populated, or for some reason the driver
starts at a different sgl, it will break. You'll need to somehow
show none of those possibilities are happening.

Jason