Re: [RFC] pass through support in fc transport: via bsg (block SG)

[Andrew Vasquez <andrew.vasquez@qlogic.com>]

On Fri, 22 Aug 2008, James Smart wrote:

> Nope - not forgotten, just a lot of different things to get to.
>
> I don't know of anything in the header that needs to be specified. 
> Everything is either fixed because it is an ELS/CT request, or what needs 
> to be specified (usually S_ID/D_ID) comes from the object the bsg reference 
> is to. CS_CTL is the only one that is a maybe - but that's a whole 
> different story, and we should just ignore it for now. So I'm against a 
> header.
>
> Additionally, we have to be careful about what kind of interface we believe 
> the LLD's support. If they expected a raw frame transmit, I don't know how 
> many support that, especially as adapters very much control XID's, etc. 
> Create Exchange, w/ Send/Receive, sequence is prefered, but even that might 
> be too low.  At best, there is explicit els or ct assist interfaces - which 
> means the LLD/adapter is likely handling all the header and segmentation, 
> and the interface is just passing payload buffers.

That's essentially what prompted this inquiry.  Sure, for hardware
CNA/HBA solutions, access to something like a raw-frame header seems
unnecessary.  What about software FCoE?  Would the openfcoe want this
export/expose these raw-frame data?

> So in general it's a request, w/ xmt payload, buffer for response, and a  
> completion status (which I would assume is more than just an int and a 
> couple of #defines - we have to cover the F_RJT/P_RJT/ABORT cases..)

--
av