Re: [RFC] FC pass thru - Rev V

Boaz Harrosh
2009-03-08T15:47:05Z

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