On Fri, 2009-11-20 at 11:20 -0800, Joe Eykholt wrote: > Allow FC-4 provider modules to hook into libfc. > > A FC-4 provider is an upper level driver for a specific FC-4 type, > such as ELS, FCP, and possibly someday even IP. > > This allows any FC-4 module to handle PRLI requests for its type > and maintain process-association states (sessions). > > There are two possible types for providers, passive and active. > An active provider is like the FCP initiator. It normally doesn't > accept requests. A passive provider is like FCP targets, which > accept requests, and don't normally do discovery or log into other > remote ports. > > Each provider registers its ops with libfc, including prli, prlo, > recv, and abts. The provder will be called for any incoming PRLI > for that FC-4 type on any rport. It may decide to accept or > reject the PRLI. > > If it accepts the PRLI, it may keep some private state (a session or > process association) that helps it handle incoming requests. > > The provider prlo op is called on each incoming PRLO and also > whenever the remote port becomes non-ready (implicit PRLO). > The provider can use that to remove its private state. > > Type 0 is also handled this way, just for the special cases in PRLI. > > Normal ELS requests are also handled through this mechanism, > as fc_lport registers a passive provider for FC_TYPE_ELS. > > Initiator PRLIs are handled through the passive provider for FC_TYPE_FCP. > > Target PRLIs and incoming FCP requests would be handled through an > active provider for FC_TYPE_FCP. A target module would depend on > libfc by calling fc_fc4_register_provider(), and could depend on > other modules (e.g., TCM or SCST) to implement target functionality. > > One issue TBD: there's no lock taken on incoming FC4-requests, > and should be that way for good performance. There's > nothing to protect against the FC-4 provider being removed. > Perhaps an RCU mechanism can help here at low performance impact. > > Signed-off-by: Joe Eykholt <[email protected]> > --- > drivers/scsi/libfc/fc_libfc.h | 7 ++ > drivers/scsi/libfc/fc_lport.c | 70 +++++++++++++--- > drivers/scsi/libfc/fc_rport.c | 182 > +++++++++++++++++++++++++++++++++++------ > include/scsi/libfc.h | 26 ++++++ > 4 files changed, 245 insertions(+), 40 deletions(-) >
So the lport would register for ELS, the FCP layer (or some target layer) would register for SCSI-FCP and when a frame of that FC-4 was received the providers handler routine would be called? How would discovery get started with the providers? The FC-4 SCSI (initiator) provider would only get called with a PRLI response. Currently we start discovery on a SCR response. I think we'd want to add some of this to more common code somehow. I don't think the FC transport is appropriate since it's FCP (initiator) specific, but some other place so that all FC HBAs could benefit. Unfortunately, I don't think that there's a good place for it yet. Hopefully, we'll have some FC infrastructure code that you can add it to once the FC device layout infrastructure becomes more mature. Broadening this a bit- how would a FC/FCoE HBA select which FC-4 type to use for a given port? For fcoe.ko it could be a sysfs file, since we already require sysfs interaction to start, but other HBAs initiate on link-up and probably don't want to wait for a sysfs call to start. The LLD could indicate that it supported multiple FC-4s, but how would it be decided which one(s) would be registered with the name server or if discovery should be started or not? _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
