Re: [RFC] FC pass thru - Rev V

[James Smart <James.Smart@Emulex.Com>]

>> 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