[ofa-general] Re: commit bb350d1decd9c48ffaa7f7e263df3056df9f4f21

FUJITA Tomonori fujita.tomonori at lab.ntt.co.jp
Mon Jul 23 04:20:55 PDT 2007


From: "Michael S. Tsirkin" <mst at dev.mellanox.co.il>
Subject: commit bb350d1decd9c48ffaa7f7e263df3056df9f4f21
Date: Mon, 23 Jul 2007 10:57:54 +0300

> Hi!
> commit bb350d1decd9c48ffaa7f7e263df3056df9f4f21 includes this snippet:
> 
> @@ -468,20 +465,8 @@ static void srp_unmap_data(struct scsi_cmnd *scmnd,
>                 req->fmr = NULL;
>         }
> 
> -       /*
> -        * This handling of non-SG commands can be killed when the
> -        * SCSI midlayer no longer generates non-SG commands.
> -        */
> -       if (likely(scmnd->use_sg)) {
> -               nents = scmnd->use_sg;
> -               scat  = scmnd->request_buffer;
> -       } else {
> -               nents = 1;
> -               scat  = &req->fake_sg;
> -       }
> -
> -       ib_dma_unmap_sg(target->srp_host->dev->dev, scat, nents,
> -                       scmnd->sc_data_direction);
> +       ib_dma_unmap_sg(target->srp_host->dev->dev, scsi_sglist(scmnd),
> +                       scsi_sg_count(scmnd), scmnd->sc_data_direction);
> 
> Since scsi_sg_count is simply use_sg, and scsi_sglist is simply request_buffer,
> why is this the right things to do?

That will change shortly.

http://marc.info/?l=linux-scsi&m=118364319919621&w=2


> Is there a reason to believe that scsi_sg_count is never 0 here?

Yeah, scsi-ml doesn't send non-SG commands now.



More information about the general mailing list