James Smart wrote: >>> 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). > Or force a block bounce buffers by setting the queue alignment requirements (Can only work for max transfer of PAGE_SIZE/2 ) > 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 Boaz -- 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
