Re: Proposal to add sysfs attributes for FCoE in FC Transport layer

[James Smart <James.Smart@Emulex.Com>]

Robert Love wrote:
> On Wed, 2009-04-01 at 09:59 -0400, James Smart wrote:
>> The largest issue I have is - what attributes are really fc/fcoe specific ?
>> DCBX and PFC are arguably NIC-related parameters and have no business being
>> under the fc transport.  Additionally, whatever we pick, we had better put
>> the same or like parameters with lib_fcoe-supporting adapters in the same
>> place.
>>
>> This is very muddy as some adapters will want present a fc/scsi function
>> only, hiding the nic completely; others may present a nic function and
>> an fcoe function, and physically share the nic; while others will have
>> only the nic and a bunch of software, or a nic with super-features for
>> fcoe.  What object belongs where for what attribute ?
>>
>> Another thing that should be brought up is the presentation model when
>> there are multiple FCF's that an FCOE adapter can talk to. I'm a fan of
>> having a new fc_host for every new *initiator* context on a fabric.
>> Meaning, there's a fc_host for each N_Port_Id on each fabric (which is
>> what we have been doing for NPIV and VSANs). Mean an FCOE port, which
>> sees multiple FCFs, or contacts the same FCF on different vlans (which
>> map to different VSANs) need to be separate fc_hosts.  Additionally, we
> 
> What do you think about having a fcoe_host defined in the FC transport
> that can exist for the FIP phase and then create fc_hosts for each
> N_Port_ID that is logged into the fabric(s)? 

I don't think it meshes very well. If we're going to create a new "top"
object, I'd rather it became a generic fc port (or bus/adapter, as I'd
want to move it above the 1st scsi_host).  This object could then have
"type" attributes, or even a std FC or FCOE subclass, then the fc_hosts
under it.

> We could also have a fcoe_fcf structure that would have a similar
> relationship with the fcoe_host that the rports have with the fc_host
> (at least from the device model perspective). I don't think the
> fcoe_host would be coupled with a scsi_host, or fc_host, since there is
> no intent to use it for I/O, it would be used to do FIP and then we
> switch to fc_hosts just before we log a port into a fabric.

Agreed in concept, thus my push for fc being a bus-like object.

We'll need to work this further. It means creating a small subtree
of objects - from the adapter; to an egress port/point (a single FC
port, or 1 per mac or mac/vlan ?); to fabric ingress point (aka FC
Fport, or FCF's); to a set of fabrics (VSAN hdrs or VLAN related);
to fc_vport (an N_Port_ID on a fabric); to scsi_host/fc_host (initiator
role on the fc_vport); (consider tgt mode attachment to a fc_vport);
to ...rest of current initiator-based rport/stgt/slun tree....

This part concerns me as the scope is a bit large.

> 
> libfcoe has two structures that are used for this purpose
> (include/scsi/libfcoe.h), but they're only used by modules that use
> libfcoe. Maybe they should be moved up to the transport layer, modified
> to fit into the the device model and then have the relevant info exposed
> in sysfs.

Agreed.  Although, we're going to touch on the same kind of issues
you had with rports - can you actively use the entity for internal
topology and state management, or is it only in the transport in order
for mgmt presentation and control.

-- james s