Re: [RFC] FC pass thru - Rev V

[Boaz Harrosh <bharrosh@panasas.com>]

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