scsi_fc_transport.txt

linux 内核源代码

      encountered:
       - The FC topology is not Point-to-Point
       - The FC port is not connected to an F_Port
       - The F_Port has indicated that NPIV is not supported.

    FC_VPORT_NO_FABRIC_RSCS     - No Fabric Resources
      The vport is not operational. The Fabric failed FDISC with a status
      indicating that it does not have sufficient resources to complete
      the operation.

    FC_VPORT_FABRIC_LOGOUT      - Fabric Logout
      The vport is not operational. The Fabric has LOGO'd the N_Port_ID
      associated with the vport.

    FC_VPORT_FABRIC_REJ_WWN     - Fabric Rejected WWN
      The vport is not operational. The Fabric failed FDISC with a status
      indicating that the WWN's are not valid.

    FC_VPORT_FAILED             - VPort Failed
      The vport is not operational. This is a catchall for all other
      error conditions.


  The following state table indicates the different state transitions:

    State              Event                            New State
    --------------------------------------------------------------------
     n/a                Initialization                  Unknown
    Unknown:            Link Down                       Linkdown
                        Link Up & Loop                  No Fabric Support
                        Link Up & no Fabric             No Fabric Support
                        Link Up & FLOGI response        No Fabric Support
                          indicates no NPIV support
                        Link Up & FDISC being sent      Initializing
                        Disable request                 Disable
    Linkdown:           Link Up                         Unknown
    Initializing:       FDISC ACC                       Active
                        FDISC LS_RJT w/ no resources    No Fabric Resources
                        FDISC LS_RJT w/ invalid         Fabric Rejected WWN
                          pname or invalid nport_id
                        FDISC LS_RJT failed for         Vport Failed
                          other reasons
                        Link Down                       Linkdown
                        Disable request                 Disable
    Disable:            Enable request                  Unknown
    Active:             LOGO received from fabric       Fabric Logout
                        Link Down                       Linkdown
                        Disable request                 Disable
    Fabric Logout:      Link still up                   Unknown

         The following 4 error states all have the same transitions:
    No Fabric Support:
    No Fabric Resources:
    Fabric Rejected WWN:
    Vport Failed:
                        Disable request                 Disable
                        Link goes down                  Linkdown


Transport <-> LLDD Interfaces :
-------------------------------

Vport support by LLDD:

  The LLDD indicates support for vports by supplying a vport_create()
  function in the transport template.  The presense of this function will
  cause the creation of the new attributes on the fc_host.  As part of
  the physical port completing its initialization relative to the
  transport, it should set the max_npiv_vports attribute to indicate the
  maximum number of vports the driver and/or adapter supports.


Vport Creation:

  The LLDD vport_create() syntax is:

      int vport_create(struct fc_vport *vport, bool disable)

    where:
      vport:    Is the newly allocated vport object
      disable:  If "true", the vport is to be created in a disabled stated.
                If "false", the vport is to be enabled upon creation.

  When a request is made to create a new vport (via sgio/netlink, or the
  vport_create fc_host attribute), the transport will validate that the LLDD
  can support another vport (e.g. max_npiv_vports > npiv_vports_inuse).
  If not, the create request will be failed.  If space remains, the transport
  will increment the vport count, create the vport object, and then call the
  LLDD's vport_create() function with the newly allocated vport object.

  As mentioned above, vport creation is divided into two parts:
    - Creation with the kernel and LLDD. This means all transport and
      driver data structures are built up, and device objects created.
      This is equivalent to a driver "attach" on an adapter, which is
      independent of the adapter's link state.
    - Instantiation of the vport on the FC link via ELS traffic, etc.
      This is equivalent to a "link up" and successfull link initialization.

  The LLDD's vport_create() function will not synchronously wait for both
  parts to be fully completed before returning. It must validate that the
  infrastructure exists to support NPIV, and complete the first part of
  vport creation (data structure build up) before returning.  We do not
  hinge vport_create() on the link-side operation mainly because:
    - The link may be down. It is not a failure if it is. It simply
      means the vport is in an inoperable state until the link comes up.
      This is consistent with the link bouncing post vport creation.
    - The vport may be created in a disabled state.
    - This is consistent with a model where:  the vport equates to a
      FC adapter. The vport_create is synonymous with driver attachment
      to the adapter, which is independent of link state.

    Note: special error codes have been defined to delineate infrastructure
      failure cases for quicker resolution.

  The expected behavior for the LLDD's vport_create() function is:
    - Validate Infrastructure:
        - If the driver or adapter cannot support another vport, whether
            due to improper firmware, (a lie about) max_npiv, or a lack of
            some other resource - return VPCERR_UNSUPPORTED.
        - If the driver validates the WWN's against those already active on
            the adapter and detects an overlap - return VPCERR_BAD_WWN.
        - If the driver detects the topology is loop, non-fabric, or the
            FLOGI did not support NPIV - return VPCERR_NO_FABRIC_SUPP.
    - Allocate data structures. If errors are encountered, such as out
        of memory conditions, return the respective negative Exxx error code.
    - If the role is FCP Initiator, the LLDD is to :
        - Call scsi_host_alloc() to allocate a scsi_host for the vport.
        - Call scsi_add_host(new_shost, &vport->dev) to start the scsi_host
          and bind it as a child of the vport device.
        - Initializes the fc_host attribute values.
    - Kick of further vport state transitions based on the disable flag and
        link state - and return success (zero).

  LLDD Implementers Notes:
  - It is suggested that there be a different fc_function_templates for
    the physical port and the virtual port.  The physical port's template
    would have the vport_create, vport_delete, and vport_disable functions,
    while the vports would not.
  - It is suggested that there be different scsi_host_templates
    for the physical port and virtual port. Likely, there are driver
    attributes, embedded into the scsi_host_template, that are applicable
    for the physical port only (link speed, topology setting, etc). This
    ensures that the attributes are applicable to the respective scsi_host.


Vport Disable/Enable:

  The LLDD vport_disable() syntax is:

      int vport_disable(struct fc_vport *vport, bool disable)

    where:
      vport:    Is vport to to be enabled or disabled
      disable:  If "true", the vport is to be disabled.
                If "false", the vport is to be enabled.

  When a request is made to change the disabled state on a vport, the
  transport will validate the request against the existing vport state.
  If the request is to disable and the vport is already disabled, the
  request will fail. Similarly, if the request is to enable, and the
  vport is not in a disabled state, the request will fail.  If the request
  is valid for the vport state, the transport will call the LLDD to
  change the vport's state.

  Within the LLDD, if a vport is disabled, it remains instantiated with
  the kernel and LLDD, but it is not active or visible on the FC link in
  any way. (see Vport Creation and the 2 part instantiation discussion).
  The vport will remain in this state until it is deleted or re-enabled.
  When enabling a vport, the LLDD reinstantiates the vport on the FC
  link - essentially restarting the LLDD statemachine (see Vport States
  above).


Vport Deletion:

  The LLDD vport_delete() syntax is:

      int vport_delete(struct fc_vport *vport)

    where:
      vport:    Is vport to delete

  When a request is made to delete a vport (via sgio/netlink, or via the
  fc_host or fc_vport vport_delete attributes), the transport will call
  the LLDD to terminate the vport on the FC link, and teardown all other
  datastructures and references.  If the LLDD completes successfully,
  the transport will teardown the vport objects and complete the vport
  removal.  If the LLDD delete request fails, the vport object will remain,
  but will be in an indeterminate state.

  Within the LLDD, the normal code paths for a scsi_host teardown should
  be followed. E.g. If the vport has a FCP Initiator role, the LLDD
  will call fc_remove_host() for the vports scsi_host, followed by
  scsi_remove_host() and scsi_host_put() for the vports scsi_host.


Other:
  fc_host port_type attribute:
    There is a new fc_host port_type value - FC_PORTTYPE_NPIV. This value
    must be set on all vport-based fc_hosts.  Normally, on a physical port,
    the port_type attribute would be set to NPORT, NLPORT, etc based on the
    topology type and existence of the fabric. As this is not applicable to
    a vport, it makes more sense to report the FC mechanism used to create
    the vport.

  Driver unload:
    FC drivers are required to call fc_remove_host() prior to calling
    scsi_remove_host().  This allows the fc_host to tear down all remote
    ports prior the scsi_host being torn down.  The fc_remove_host() call
    was updated to remove all vports for the fc_host as well.


Credits
=======
The following people have contributed to this document:






James Smart
[e-mail]