On Fri, Aug 22, 2008 at 3:09 PM, Andrew Vasquez <andrew.vasquez@xxxxxxxxxx> wrote: > 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? It's easy enough to provide software assists for lower level devices, so I'd say focus on what will work for HBAs and we'll make software FCoE work around that interface. I don't see a reason to expose any extra level of detail here, if you want to see the full frame data in the software FCoE case you can always just capture the network traffic. - Chris -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
