`

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

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.