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

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

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.

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

-- james s

Seokmann Ju wrote:
> I just want to re-stroke this thread to make sure it is not skipped.
> 
> One question came to me while testing qla2xxx module with the changes.
> When the application issues ELS/CT packet, should the packet include
> the FC frame header?
> And if the answer is 'yes', should the driver also include the FC
> frame header when it returns response to the application (just like
> any other frame exchanges in between two ports on the FC)?
> The FC frame header has type field that identifies what type of the
> payload (ELS / CT / etc.) the frame contains and the type field is
> being checked by the FC transport layer before it calls LLDD's handler.
> 
> Thank you,
> Seokmann