Joe Eykholt wrote:
> 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.
Another thought: outgoing PRLIs should be removed from the remote port
state machine and moved up to the FC-4 provider (fc_fcp.c) eventually,
since they are FC-4 specific.
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
