Re: Open-FCoE on linux-scsi

[FUJITA Tomonori <tomof@acm.org>]

On Sat, 05 Jan 2008 00:41:05 +0100
Stefan Richter <stefanr@s5r6.in-berlin.de> 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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html