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.
OK. So the whole point that I brought up is implementation specific.
Thank you for the comment.
Yes, but I wouldn't be surprised to see it occur often enough to be a
pain. What I would recommend is : if your hardware wants only one
buffer descriptor for ELSs, and there's 2 BGs, that you double-buffer
it. Allocate a local buffer, transfer the users data into the buffer,
and then use the local buffer for the hardware. Same on the receive
path. A pain, yes, but this isn't time critical stuff, and it's much
better than just returning an error to the app based on it's buffer
alignment (which it probably doesn't even realize).
The above works for ELS's (as its small), but I fully expect other
things, like CT requests, to not be small and require multiple buffers.
On those things, I hope the hardware supports multiple sg's as
double-buffering it is ugly.
-- james s
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
