Robert Love wrote:
> 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?
Yes, this patch has both FCP initiator and ELS registrations built in.
Since fnic doesn't use fc_fcp.c, I didn't want to put the FCP
registration there, but maybe that's where it should go. The PRLI
handling is common code because it's tied to scsi_transport_fc's needs.
> How would discovery get started with the providers? The FC-4 SCSI
> (initiator) provider would only get called with a PRLI response.
You mean when the remote port goes ready and the transport remote port
is added. See below.
> Currently we start discovery on a SCR response.
That's when the local port is ready.
It's up to the providers. I haven't worked that out. Targets don't
do discovery or send out PLOGIs. See below.
> 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.
It should be up to the upper layer devices, not selected by the LLDs.
It's like with networking, the Ethernet driver doesn't determine whether
UDP or TCP or both are supported, or IPv4 or IPv6 for that matter. The
LLD is just a transport. If we end up with some LLDs that can't support
certain types, we could add a way for them to indicate that to libfc.
> 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?
Good questions. I think all the registered providers should be indicated
when we register with the name service. That is, if there's an type X
provider registered, we say we support type X, but when a PRLI comes in
for type X, we may reject it anyway based on ACLs in the provider or
because the provider module has been removed.
If there's any 'active' providers, (like the FCP initiator), we should
do discovery. That would satisfy the current set of FC-4s we know about.
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
