Re: [PATCH] FC Transport support for vports based on NPIV

James Smart
2007-05-14T15:58:00Z

reposting w/ the title

James Smart wrote:
>
> Christof Schmitt wrote:
>> James,
>>
>> i try to understand what the introduction of the vports means for
>> zfcp, since
>> this driver also supports NPIV. The documentation for the fc transport
>> class
>> describes a driver that would fully control the adapter and the
>> creation of
>> virtual address. Since you mentioned Xen, i assume that this could be
>> a dom0.
>
> All true. But, there is the notion that there is a driver that thinks it's
> controlling the adapter, but it's actually talking to a virtual thing, that
> traps the driver's FLOGI's and turns it into FDISCs...
>
>> With zfcp, the hardware FCP adapter does NPIV and only hands out the
>> virtual
>> address to individual Linux instances. zfcp gets the assigned virtual
>> address
>> for the Linux instance. This address is used for allocating the scsi_host
>> structure. Basically, the whole system uses NPIV, but each Linux only
>> uses one
>> assigned virtual WWPN.
>
> Yes - I understand. For all intents and purposes, that virtual address is
> treated as an adapter.
>
>> My current understanding is that the vports introduced in the fc
>> transport
>> class do not affect the Linux systems that only use one virtual
>> address. To
>> map this to Xen, the dom0 would use the vports to show all virtual
>> address, and
>> each domU would use the assigned virtual address without showing the
>> vport in
>> sysfs. Is this correct?
>>
>> Christof
>
> Agreed. It should mean nothing to the zfcp driver. Nothing changes in
> the driver
> if it will always be a single address.
>
> Although - if your hardware-to-driver interface had the ability to
> instantiate
> a new address, you could augment your driver to support the vport calls.
> That's
> a choice for you though.
>
> -- james
>
> PS: One thing I didn't call out in the vport patches was the expectation
> that
> the vport-supporting driver had to set the PPN attribute appropriately.
> And... did you see that T11 is trying to change what the PPN is set to
> - the
> fabric port_name not the physical N_Port port_name.
>