On Sat, 05 Jan 2008 00:41:05 +0100 Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> wrote: > Dev, Vasu wrote: > [FUJITA Tomonori wrote:] > >> Agreed. My FCoE initiator design would be something like: > >> > >> scsi-ml > >> fcoe initiator driver > >> libfcoe > >> fc_transport_class (inclusing fcoe support) > >> > >> And FCoE HBA LLDs work like: > >> > >> scsi-ml > >> FCoE HBA LLDs (some of them might use libfcoe) > >> fc_transport_class (inclusing fcoe support) > > Wouldn't it make more sense to think of fc_transport_class as a FCP > layer, sitting between scsi-ml and the various FC interconnect drivers > (among them Openfc and maybe more FCoE drivers)? I.e. you have SCSI > command set layer -- SCSI core -- SCSI transport layer -- interconnect > layer.¹ Oops, I should have depicted: scsi-ml fc_transport_class (inclusing fcoe support) FCoE HBA LLDs (some of them might use libfcoe) As you pointed out, that's the correct layering from the perspective of SCSI architecture. I put FCoE HBA LLDs over fc_transport_class just because LLDs directly interact with scsi-ml to perform the main work, queuecommand/done (as you explained in 1). > I am not familiar with FCP/ FCoE/ FC-DA et al, but I guess the FCoE > support in the FCP transport layer should then go to the extent of > target discovery, login, lifetime management and representation of > remote ports and so on as far as it pertains to FCP (the SCSI transport > protocol, FC-4 layer) independently of the interconnect (FC-3...FC-0 > layers).² > > [...] > >> The FCoE LLD needs to exploit the exsting struct fc_rport and APIs. > > > > The openfc is software implementation of FC services such as FC login > > and target discovery and it is already using/exploiting existing fc > > transport class including fc_rport struct. You can see openfc using > > fc_rport in openfc_queuecommand() and using fc transport API > > fc_port_remote_add() for fc_rport. > > Hence, aren't there interconnect independent parts of target discovery > and login which should be implemented in fc_transport_class? The > interconnect dependent parts would then live in LLD methods to be > provided in struct fc_function_template. Agreed. Then FCoE helper functions that aren't useful for all the FCoE LLDs would go libfcoe like iscsi class does (and sas class also does, I guess). > I.e. not only make full use of the API of fc_transport_class, also think > about changing the API _if_ necessary to become a more useful > implementation of the interface below FC-4. > > ------- > ¹) The transport classes are of course not layers in such a sense that > they would completely hide SCSI core from interconnect drivers. They > don't really have to; they nevertheless live at a higher level of > abstraction than LLDs and a lower level of abstraction than SCSI core. > > (One obvious example that SCSI core is less hidden than it possibly > could be can be seen by the struct fc_function_template methods having > struct scsi_target * and struct Scsi_Host * arguments, instead of struct > fc_xyz * arguments.) > > ²) I'm using the term interconnect from the SCSI perspective, not from > the FC perspective. > -- > Stefan Richter > -=====-==--- ---= --=-= > http://arcgraph.de/sr/ > - > 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 - 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
