From: James Smart <James.Smart@Emulex.Com>
To: Seokmann Ju <seokmann.ju@qlogic.com>
Cc: "futjita.tomonori@lab.ntt.co.jp" <futjita.tomonori@lab.ntt.co.jp>,
Andrew Vasquez <andrew.vasquez@qlogic.com>,
"sven@linux.vnet.ibm.com" <sven@linux.vnet.ibm.com>,
"bharrosh@panasas.com" <bharrosh@panasas.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"Smart, James" <James.Smart@Emulex.Com>
Subject: Re: [RFC] FC pass thru - Rev V
Date: Sat, 7 Mar 2009 09:44:57 -0500 [thread overview]
Message-ID: <49B28869.6090507@emulex.com> (raw)
In-Reply-To: <968C4C03B4940B48A4A8B1EA417CD6D82D2639A19E@AVEXMB2.qlogic.org>
Seokmann Ju wrote:
>> From: James Smart [mailto:James.Smart@Emulex.Com]
>> Sent: Wednesday, February 11, 2009 7:14 AM
>>
>> Trying to kick-start this again...
>> I've updated the prior RFC with the comments from Seokmann,
>> SvenFujita, and Boaz. I would still like review on the
>> blk_xxx completion calls in the std and error paths.
> <snip>
>> +static int
>> +fc_bsg_map_buffer(struct fc_bsg_buffer *buf, struct request *req)
>> +{
>> + size_t sz = (sizeof(struct scatterlist) * req->nr_phys_segments);
>> +
>> + BUG_ON(!req->nr_phys_segments);
>> +
>> + buf->sg_list = kzalloc(sz, GFP_KERNEL);
>> + if (!buf->sg_list)
>> + return -ENOMEM;
>> + sg_init_table(buf->sg_list, req->nr_phys_segments);
>> + buf->sg_cnt = blk_rq_map_sg(req->q, req, buf->sg_list);
>> + buf->payload_len = req->data_len;
>> + return 0;
>> +}
> It looks like that there is possibility that the dma buffer with more
> than one sg element for ELS services - which is not allowed per FC spec.
How can the T11 FC spec ever reference anything about sg elements ? They
are completely independent.
> I've seen a couple of times from the driver testing.
> I'm looking for some ways to making sure the ELS services
> to get single sg for both request/reply_payload.
> Any comments/suggestion?
For ELS's, the payload should be small - usually <= 256bytes so it fits
within default login parameters. It should be 1 buffer, thus 1 sge.
(Note: the routine above is for any request, which covers more than just
ELS's).
If you're getting multiple sg's, then either the buffer spans some
condition that crosses a boundary that blk_rq_map_sg() enforces (like a
4G boundary, but I doubt that's it), or - and more likely - your
application has a buffer that spans 2 pages which look contiguous to the
app, but are actually virtual-memory mapped to 2 independent physical
pages (thus the need for 2 sg's). If your app knows the system page
size, and was careful about buffer placement and length within page
boundaries, it likely would never encounter this. But, we would never
want to force apps to be this smart, and this would be a good
justification for supporting more than 1 sg.
-- james s
next prev parent reply other threads:[~2009-03-07 14:45 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-18 21:24 [RFC] FC pass thru - Rev IV James Smart
2008-11-24 15:46 ` Sven Schuetz
2008-11-24 16:29 ` James Smart
2008-11-25 15:08 ` Sven Schuetz
2008-11-25 15:56 ` James Smart
2008-11-24 20:37 ` Seokmann Ju
2008-11-24 21:03 ` James Smart
2008-11-25 14:38 ` Seokmann Ju
2008-11-25 15:47 ` James Smart
2008-12-01 21:49 ` Seokmann Ju
2008-12-01 22:09 ` James Smart
2008-11-26 18:25 ` Sven Schuetz
2008-11-26 18:58 ` James Smart
2008-11-27 7:03 ` FUJITA Tomonori
2008-11-27 8:58 ` Boaz Harrosh
2008-11-27 9:53 ` FUJITA Tomonori
2008-11-27 11:51 ` Boaz Harrosh
2008-11-28 1:52 ` FUJITA Tomonori
2008-11-30 10:56 ` Boaz Harrosh
2008-11-28 2:01 ` James Bottomley
2008-11-28 2:22 ` FUJITA Tomonori
2009-02-11 15:13 ` [RFC] FC pass thru - Rev V James Smart
2009-02-11 15:43 ` Seokmann Ju
2009-02-20 2:33 ` Seokmann Ju
2009-02-20 18:53 ` James Smart
2009-02-21 6:00 ` FUJITA Tomonori
2009-02-24 14:25 ` Seokmann Ju
2009-03-13 16:25 ` Seokmann Ju
2009-03-13 16:47 ` Sven Schuetz
2009-03-13 17:04 ` Seokmann Ju
2009-03-15 9:34 ` Boaz Harrosh
2009-03-15 13:14 ` James Smart
2009-03-15 14:03 ` Boaz Harrosh
2009-03-15 15:15 ` James Smart
2009-03-15 16:15 ` Boaz Harrosh
2009-03-15 14:26 ` Boaz Harrosh
2009-03-19 1:57 ` FUJITA Tomonori
2009-03-14 22:16 ` James Smart
2009-03-16 11:36 ` Seokmann Ju
2009-03-25 12:58 ` Seokmann Ju
2009-03-15 9:30 ` Boaz Harrosh
2009-03-16 11:40 ` Seokmann Ju
2009-03-16 13:38 ` Boaz Harrosh
2009-03-16 15:37 ` Seokmann Ju
2009-02-11 16:15 ` Boaz Harrosh
2009-02-11 16:33 ` FUJITA Tomonori
2009-02-11 16:55 ` Boaz Harrosh
2009-02-11 17:14 ` FUJITA Tomonori
2009-02-11 18:16 ` Boaz Harrosh
2009-03-07 12:17 ` Seokmann Ju
2009-03-07 14:44 ` James Smart [this message]
2009-03-07 20:18 ` Seokmann Ju
2009-03-08 15:00 ` James Smart
2009-03-08 15:46 ` Boaz Harrosh
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=49B28869.6090507@emulex.com \
--to=james.smart@emulex.com \
--cc=andrew.vasquez@qlogic.com \
--cc=bharrosh@panasas.com \
--cc=futjita.tomonori@lab.ntt.co.jp \
--cc=linux-scsi@vger.kernel.org \
--cc=seokmann.ju@qlogic.com \
--cc=sven@linux.vnet.ibm.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