linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Sultan Alsawaf <sultan@kerneltoast.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	Thomas Hellstrom <thellstrom@vmware.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Ming Lei <ming.lei@redhat.com>,
	Gal Pressman <galpress@amazon.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scatterlist: Speed up for_each_sg() loop macro
Date: Mon, 28 Oct 2019 13:23:20 -0300	[thread overview]
Message-ID: <20191028162320.GF29652@ziepe.ca> (raw)
In-Reply-To: <20191028161848.GA32593@sultan-box.localdomain>

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

  reply	other threads:[~2019-10-28 16:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25 21:33 [PATCH] scatterlist: Speed up for_each_sg() loop macro Sultan Alsawaf
2019-10-28 14:17 ` Jason Gunthorpe
2019-10-28 16:18   ` Sultan Alsawaf
2019-10-28 16:23     ` Jason Gunthorpe [this message]
2019-10-28 16:28       ` Christoph Hellwig
2019-10-28 16:37         ` Sultan Alsawaf
2019-10-28 16:29       ` Sultan Alsawaf
2019-10-28 23:46 ` kbuild test robot
2019-10-29  2:25 ` Ming Lei
2019-11-01  3:33 ` [scatterlist] 8f39742f03: suspend_stress.fail kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191028162320.GF29652@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=galpress@amazon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ming.lei@redhat.com \
    --cc=palmer@sifive.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sultan@kerneltoast.com \
    --cc=thellstrom@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).