FC bus questions

FC bus questions

[Robert Love]

Hi James (and everyone else),

   I wanted to continue the discussion on FCoE statistics and a possible
device tree reorganization. The original thread has been expired from my
mail system, so I have to start this new thread. The main theme was that
we might want to convert FC to be a bus.

   For reference here is your proposed sysfs layout-

/sys/.../fcportX/fcfportY/fcfabricZ/fcvportA/fcrportB
                                            /fcpinitC/hostD/target<H:C:T>/<H:C:T>

   I can see a benefit to extending the FC device tree. Assuming that
each of these devices is created as they're discovered by the FC HBA
then it's giving a more accurate description of the system's state. For
example, in FCoE if you were to succeed with FIP and discover a FCF, but
the FLOGI failed then user space could clearly see that devices were
only created up to the fcfabric. I also think that it simply makes more
room for new attributes. With FCFs and FCoE attributes it would be nice
to have them better organized instead of just grouping them all under
the fc_host.

   Aside from a sysfs reorganization, which could be done without making
FC a bus, the main benefit seems to be that other FC4 protocols could
use a FC HBA. Is there other goodness that I'm overlooking?

   Also, buses usually have devices and drivers. I'm not sure what the
FC drivers would be since SCSI would ultimately provide the drivers for
SCSI-FCP. Would a FC bus only have devices and no drivers?

Thanks, //Rob

Re: FC bus questions

[Giridhar Malavali]

On Nov 16, 2009, at 10:44 AM, Robert Love wrote:

> Hi James (and everyone else),
>
>   I wanted to continue the discussion on FCoE statistics and a  
> possible
> device tree reorganization. The original thread has been expired  
> from my
> mail system, so I have to start this new thread. The main theme was  
> that
> we might want to convert FC to be a bus.
>
>   For reference here is your proposed sysfs layout-
>
> /sys/.../fcportX/fcfportY/fcfabricZ/fcvportA/fcrportB
>                                            /fcpinitC/hostD/ 
> target<H:C:T>/<H:C:T>
>
>   I can see a benefit to extending the FC device tree. Assuming that
> each of these devices is created as they're discovered by the FC HBA
> then it's giving a more accurate description of the system's state.  
> For
> example, in FCoE if you were to succeed with FIP and discover a FCF,  
> but
> the FLOGI failed then user space could clearly see that devices were
> only created up to the fcfabric. I also think that it simply makes  
> more
> room for new attributes. With FCFs and FCoE attributes it would be  
> nice
> to have them better organized instead of just grouping them all under
> the fc_host.

Yes. I feel treating FC as bus make better understanding then host.  
This clearly has advantages.

Various FCoE attributes which are basically NIC specific but belongs  
to FCoE from protocol perspective can be grouped under FCoE directory  
to start with.

>
>
>   Aside from a sysfs reorganization, which could be done without  
> making
> FC a bus, the main benefit seems to be that other FC4 protocols could
> use a FC HBA. Is there other goodness that I'm overlooking?
>

Adding different FC4 protocols under FC HBA was not giving right sense  
from complete system perspective. For ex: adding FCoE specific
information in FC HBA. I feel the other approach will give much clarity.


>   Also, buses usually have devices and drivers. I'm not sure what the
> FC drivers would be since SCSI would ultimately provide the drivers  
> for
> SCSI-FCP. Would a FC bus only have devices and no drivers?
>
> Thanks, //Rob
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FC bus questions

[James Smart]

Robert Love wrote:
> Hi James (and everyone else),
> 
>    I wanted to continue the discussion on FCoE statistics and a possible
> device tree reorganization. The original thread has been expired from my
> mail system, so I have to start this new thread. The main theme was that
> we might want to convert FC to be a bus.
> 
>    For reference here is your proposed sysfs layout-
> 
> /sys/.../fcportX/fcfportY/fcfabricZ/fcvportA/fcrportB
>                                             /fcpinitC/hostD/target<H:C:T>/<H:C:T>
> 
>    I can see a benefit to extending the FC device tree. Assuming that
> each of these devices is created as they're discovered by the FC HBA
> then it's giving a more accurate description of the system's state. For
> example, in FCoE if you were to succeed with FIP and discover a FCF, but
> the FLOGI failed then user space could clearly see that devices were
> only created up to the fcfabric. I also think that it simply makes more
> room for new attributes. With FCFs and FCoE attributes it would be nice
> to have them better organized instead of just grouping them all under
> the fc_host.
> 
>    Aside from a sysfs reorganization, which could be done without making
> FC a bus, the main benefit seems to be that other FC4 protocols could
> use a FC HBA. Is there other goodness that I'm overlooking?

The 2 main gripes I hoped it would solve are:

- Right now, FC things always have a scsi_host "hostD" object that binds to 
the physical parent (usually the pci adapter object), then the fc objects 
appear under it. This relationship is very odd - especially if the fc-thing 
isn't acting as an fcp initiator, or if the sub-objects are scsi-hosts in 
their own right. And the fact its the location of driver-specific attributes 
makes it further odd  (why is one scsi_host different from another - why 
aren't the driver-specific attributes on the pci adapter object instead).

- As you point out - much better clarity and organization of attributes and a 
better representation of bus/connectivity heirarchy.


> 
>    Also, buses usually have devices and drivers. I'm not sure what the
> FC drivers would be since SCSI would ultimately provide the drivers for
> SCSI-FCP. Would a FC bus only have devices and no drivers?

I probably took too much latitude with the word "bus", as I was thinking more 
toward the sysfs object tree rather than the linux bus/device/driver 
relationships.  Yes, it probably means no drivers as it should be as light as 
possible. I think of this as a fancy "driver" that creates it's own 
sub-objects, using the transport to do all the "fancy" work for the driver and 
in a single manner for all drivers. Fundamentally moves the scsi_host binding 
to a different place, and the correlations to class objects as well.

Thinking about the recent DMA issues with scsi - scsi should make every 
scsi_host convert over to the specifying a physical dma parent when it does 
scsi_add_host().

-- james s