Re: [PATCH] fc transport: new attributes for NPIV

Re: [PATCH] fc transport: new attributes for NPIV

[James Smart]

> Problem is that on the mainframe I don't have access to the primary
> port. Virtualization is done in adapter microcode. I just have
> access to the virtual port.

I was afraid you'd say this... that was the other caveat.

OK - given that the primary port doesn't exist what you have makes
a lot of sense. I guess we have the 2 options:
- add the 2 attributes per host
- create a host and set the attributes  (and this is major overkill)

I have some reservations about the data passing that allows the virtual
port to get the physical port data, but it's probably manageable.

With this direction - your patch is fine, with the caveat that I want
to explore the most meaningful names for the attributes. Does port_name
and physical_port_name become odd to a user ? Is some script writer bound
to assume they always wanted the physical name as they would only see a
difference if on a mainframe ? What if we change the names to be more
npiv-centric.  What about ppn (for physical_port_name) and ppn_id (for
physical_port_id) ?

> Seems that requirements for workstations and mainframes are quite
> contrary.

Not really - just there are several different implementation models, both at
the adapter and at the OS side.

-- james

Re: [PATCH] fc transport: new attributes for NPIV

[Christoph Hellwig]

On Thu, Jan 05, 2006 at 12:28:45PM -0500, James Smart wrote:
> 
> >Problem is that on the mainframe I don't have access to the primary
> >port. Virtualization is done in adapter microcode. I just have
> >access to the virtual port.
> 
> I was afraid you'd say this... that was the other caveat.
> 
> OK - given that the primary port doesn't exist what you have makes
> a lot of sense. I guess we have the 2 options:
> - add the 2 attributes per host
> - create a host and set the attributes  (and this is major overkill)
> 
> I have some reservations about the data passing that allows the virtual
> port to get the physical port data, but it's probably manageable.
> 
> With this direction - your patch is fine, with the caveat that I want
> to explore the most meaningful names for the attributes. Does port_name
> and physical_port_name become odd to a user ? Is some script writer bound
> to assume they always wanted the physical name as they would only see a
> difference if on a mainframe ? What if we change the names to be more
> npiv-centric.  What about ppn (for physical_port_name) and ppn_id (for
> physical_port_id) ?

Actually I think even for Xen-like virtualization it makes most sense that
most domains wouldn't see the Scsi_Host for the phyisical port so this solution
looks most sane to me.  The long name for the physical names sounds fine to me
aswell, much better than un-understandable three-latter acronyms :)

Re: [PATCH] fc transport: new attributes for NPIV

[James Smart]

Christoph Hellwig wrote:
> Actually I think even for Xen-like virtualization it makes most sense that
> most domains wouldn't see the Scsi_Host for the phyisical port so this solution
> looks most sane to me.  The long name for the physical names sounds fine to me
> as well, much better than un-understandable three-latter acronyms :)

So my grind is just with the "physical_port_xxx" reference. It's too logical
of a name for someone uninitiated with NPIV. How do they know the difference
between physical_port_name and port_name, especially where the predominance of
configs will always have the same values in both attributes ? Choosing
something "physical" always seem like a better choice.

I should have known better on the abbreviation.... :)

Having made this argument - I then said - why not use the name from the
standards, "permanent_port_xxx". But, when I look at this, it's not much 
different. Permanent vs Physical ? at least the abbreviation gave it some
separation. Bah Humbug. My preference is still "permanent" over "physical"
as it tracks the standards name.

-- james

Re: [PATCH] fc transport: new attributes for NPIV

[Andreas Herrmann]

On 09.01.2006 20:04 James Smart <James.Smart@Emulex.Com> wrote:
> Christoph Hellwig wrote:
> > Actually I think even for Xen-like virtualization it makes most sense 
that
> > most domains wouldn't see the Scsi_Host for the phyisical port so this 
solution
> > looks most sane to me.  The long name for the physical names sounds 
fine to me
> > as well, much better than un-understandable three-latter acronyms :)
[... snip ...]
> Having made this argument - I then said - why not use the name from the
> standards, "permanent_port_xxx". But, when I look at this, it's not much 

> different. Permanent vs Physical ? at least the abbreviation gave it 
some
> separation. Bah Humbug. My preference is still "permanent" over 
"physical"
> as it tracks the standards name.

I think physical_port_name was not the right choice. Sticking to
standards the name should be permanent_port_name. So people familiar
with FC standards have an idea what it is and all others are able to
find an explanation in FC-GS-4.

But introducing a permanent_port_id will lead to confusion:
Interpretation as "permanent port_id" is wrong because a port_id is
anything but "permanent".

In conclusion James' suggestion of attributes ppn and ppn_id has some
advantage.

And now comes the funny part:
Question is, do I need the port_id of the physical port at all?  In
order to determine problems with a virtual port I might have to check
whether the physical port is properly connected and logged in to the
fabric. Furthermore configuration of the corresponding switch port
should be checked. (E.g. switch might allow to set limits for the
number of NPIV connections for the switch port.)
I may be wrong but I think the port_id of the physical port is not
needed for this purpose.

Thus, how about introducing just what is really needed:
Introduce permanent_port_name attribute (and leave out port_id of the
physical port).

BTW, the permanent_port_name attribute of the virtual port suffices to
identify the fc_host of the physical port if there is a
representation.
And I think an LLDD should configure this attribute only for virtual
ports.


Regards,

Andreas

Re: [PATCH] fc transport: new attributes for NPIV

[James Smart]

Andreas Herrmann wrote:
> I think physical_port_name was not the right choice. Sticking to
> standards the name should be permanent_port_name. So people familiar
> with FC standards have an idea what it is and all others are able to
> find an explanation in FC-GS-4.
> 
> But introducing a permanent_port_id will lead to confusion:
> Interpretation as "permanent port_id" is wrong because a port_id is
> anything but "permanent".

Agreed. In truth, even the permanent_port_name, relative to the virtual
port, is also anything but permanent.

> In conclusion James' suggestion of attributes ppn and ppn_id has some
> advantage.
> 
> And now comes the funny part:
> Question is, do I need the port_id of the physical port at all?

In my opinion - no...

 >  In
> order to determine problems with a virtual port I might have to check
> whether the physical port is properly connected and logged in to the
> fabric. Furthermore configuration of the corresponding switch port
> should be checked. (E.g. switch might allow to set limits for the
> number of NPIV connections for the switch port.)
> I may be wrong but I think the port_id of the physical port is not
> needed for this purpose.
> 
> Thus, how about introducing just what is really needed:
> Introduce permanent_port_name attribute (and leave out port_id of the
> physical port).

Works for me.

-- james s

> 
> BTW, the permanent_port_name attribute of the virtual port suffices to
> identify the fc_host of the physical port if there is a
> representation.
> And I think an LLDD should configure this attribute only for virtual
> ports.
> 
> 
> Regards,
> 
> Andreas
> 
> 

Re: [PATCH] fc transport: new attributes for NPIV

[Andreas Herrmann]

On 09.01.2006 19:05 Christoph Hellwig <hch@infradead.org> wrote:
> On Thu, Jan 05, 2006 at 12:28:45PM -0500, James Smart wrote:
> > 
> > >Problem is that on the mainframe I don't have access to the primary
> > >port. Virtualization is done in adapter microcode. I just have
> > >access to the virtual port.
> > 
> > I was afraid you'd say this... that was the other caveat.
> > 
> > OK - given that the primary port doesn't exist what you have makes
> > a lot of sense. I guess we have the 2 options:
> > - add the 2 attributes per host
> > - create a host and set the attributes  (and this is major overkill)
> > 
[...snip...]
> Actually I think even for Xen-like virtualization it makes most sense 
that
> most domains wouldn't see the Scsi_Host for the phyisical port so this 
solution
> looks most sane to me.  The long name for the physical names sounds fine 
to me
> aswell, much better than un-understandable three-latter acronyms :)

Another general point of interest is fc_host_statistics for virtual
and physical ports.

There are some stats (most or all non fc4 stats) that only make sense
for the physical port. And there are the fc4 stats that might be
determined for the virtual port.

Having the (overkill) solution of a host for the physical port would
help to sort things out. You could provide
- complete fc_host_statistics for the physical port,
- separate fc4 statistics for each virtual port.

Without a host for the physical port you have the choice between:

(a) providing same fc_host_statistics (of the physical port) for all
virtual ports with the same permanent port name

(b) providing a combination of non fc4 stats of physical port and fc4
stats of virtual port in fc_host_statistics for a virtual port

zfcp currently does (a) with one of the patches sent last week.

Implementing (a) the per virtual port fc4 statistics are missing.
Implementing (b) the overall fc4 statistics are missing which might
help to determine the utilization of the physical link.

But I don't think this justifies the introduction of a dummy-host for
the physical port in case the physical port is not represented by a
normal host.


Regards,

Andreas

Re: [PATCH] fc transport: new attributes for NPIV

[James Smart]

Andreas Herrmann wrote:
> Another general point of interest is fc_host_statistics for virtual
> and physical ports.
> 
> There are some stats (most or all non fc4 stats) that only make sense
> for the physical port. And there are the fc4 stats that might be
> determined for the virtual port.

Yep - good point.  Odds are, to make the mgmt apps happy, and as hbaapi
to date has no distinction about virtual ports - we probably want the
stats to reflect only the stats for the scsi_host. E.g Each virtual host
shows it's own. If the physical host shows no devices and can't be accessed
directly, then it could show aggregate stats. Otherwise, it should show
only the stats for the traffic it is initiating.

Looking at hbaapi, which the stats were tuned for, I would lean toward
replicating link state/type, etc of the physical link. We could introduce
a new type - npiv or nport_id_virt, so that you could tell at a glance it's
not a real link.

> 
> Having the (overkill) solution of a host for the physical port would
> help to sort things out. You could provide
> - complete fc_host_statistics for the physical port,
> - separate fc4 statistics for each virtual port.
> 
> Without a host for the physical port you have the choice between:
> 
> (a) providing same fc_host_statistics (of the physical port) for all
> virtual ports with the same permanent port name
> 
> (b) providing a combination of non fc4 stats of physical port and fc4
> stats of virtual port in fc_host_statistics for a virtual port
> 
> zfcp currently does (a) with one of the patches sent last week.

Yep. Getting frame-level counters out of hardware, sorted by context, is
difficult. So, what you are doing is not unreasonable. Hopefully we can
make this better in the future. In the meantime - the documentation for
each driver should spell out clearly what it's reporting.

> 
> Implementing (a) the per virtual port fc4 statistics are missing.
> Implementing (b) the overall fc4 statistics are missing which might
> help to determine the utilization of the physical link.
> 
> But I don't think this justifies the introduction of a dummy-host for
> the physical port in case the physical port is not represented by a
> normal host.

Agreed...

We're still in infancy here. I also think that XEN environments will throw 
interesting wrinkles into anything we do now.


-- james s

> 
> 
> Regards,
> 
> Andreas
> 
> 

[PATCH] fc transport: new attributes for NPIV

[Andreas Herrmann]

From: Andreas Herrmann <aherrman@de.ibm.com>

[PATCH] fc transport: new attributes for NPIV

With NPort-Id-Virtualization (NPIV) "virtual" ports can be
registered at an FC switch using one physical FC port.
Using FDISC an already logged in port can login additional
ports to the Fabric. Each addtional port gets assigned a
new destination ID (see FDISC description in FC-FS).
For problem determination it is useful to know not only the
virtual port name and its associated port id but also the
port name and port id of the physical port - the port that
initially logged into the Fabric.

I suggest to add new attributes (physical_port_name and
physical_port_id) to scsi_transport_fc.

Signed-off-by: Andreas Herrmann <aherrman@de.ibm.com>

---

 drivers/scsi/scsi_transport_fc.c |    7 +++++++
 include/scsi/scsi_transport_fc.h |    9 +++++++++
 2 files changed, 16 insertions(+), 0 deletions(-)

8f1f64a50977add786fdd14a0cbc13aae4bfa89f
diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 685b997..365529a 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -295,6 +295,7 @@ static int fc_host_setup(struct transpor
 	 */
 	fc_host_node_name(shost) = -1;
 	fc_host_port_name(shost) = -1;
+	fc_host_physical_port_name(shost) = -1;
 	fc_host_supported_classes(shost) = FC_COS_UNSPECIFIED;
 	memset(fc_host_supported_fc4s(shost), 0,
 		sizeof(fc_host_supported_fc4s(shost)));
@@ -306,6 +307,7 @@ static int fc_host_setup(struct transpor
 		sizeof(fc_host_serial_number(shost)));
 
 	fc_host_port_id(shost) = -1;
+	fc_host_physical_port_id(shost) = -1;
 	fc_host_port_type(shost) = FC_PORTTYPE_UNKNOWN;
 	fc_host_port_state(shost) = FC_PORTSTATE_UNKNOWN;
 	memset(fc_host_active_fc4s(shost), 0,
@@ -795,6 +797,8 @@ static FC_CLASS_DEVICE_ATTR(host, suppor
 
 fc_private_host_rd_attr_cast(node_name, "0x%llx\n", 20, unsigned long long);
 fc_private_host_rd_attr_cast(port_name, "0x%llx\n", 20, unsigned long long);
+fc_private_host_rd_attr_cast(physical_port_name, "0x%llx\n", 20,
+			     unsigned long long);
 fc_private_host_rd_attr(symbolic_name, "%s\n", (FC_SYMBOLIC_NAME_SIZE +1));
 fc_private_host_rd_attr(maxframe_size, "%u bytes\n", 20);
 fc_private_host_rd_attr(serial_number, "%s\n", (FC_SERIAL_NUMBER_SIZE +1));
@@ -835,6 +839,7 @@ static FC_CLASS_DEVICE_ATTR(host, speed,
 
 
 fc_host_rd_attr(port_id, "0x%06x\n", 20);
+fc_host_rd_attr(physical_port_id, "0x%06x\n", 20);
 fc_host_rd_enum_attr(port_type, FC_PORTTYPE_MAX_NAMELEN);
 fc_host_rd_enum_attr(port_state, FC_PORTSTATE_MAX_NAMELEN);
 fc_host_rd_attr_cast(fabric_name, "0x%llx\n", 20, unsigned long long);
@@ -1160,6 +1165,7 @@ fc_attach_transport(struct fc_function_t
 	count=0;
 	SETUP_HOST_ATTRIBUTE_RD(node_name);
 	SETUP_HOST_ATTRIBUTE_RD(port_name);
+	SETUP_HOST_ATTRIBUTE_RD(physical_port_name);
 	SETUP_HOST_ATTRIBUTE_RD(supported_classes);
 	SETUP_HOST_ATTRIBUTE_RD(supported_fc4s);
 	SETUP_HOST_ATTRIBUTE_RD(symbolic_name);
@@ -1168,6 +1174,7 @@ fc_attach_transport(struct fc_function_t
 	SETUP_HOST_ATTRIBUTE_RD(serial_number);
 
 	SETUP_HOST_ATTRIBUTE_RD(port_id);
+	SETUP_HOST_ATTRIBUTE_RD(physical_port_id);
 	SETUP_HOST_ATTRIBUTE_RD(port_type);
 	SETUP_HOST_ATTRIBUTE_RD(port_state);
 	SETUP_HOST_ATTRIBUTE_RD(active_fc4s);
diff --git a/include/scsi/scsi_transport_fc.h b/include/scsi/scsi_transport_fc.h
index 394f14a..13a8171 100644
--- a/include/scsi/scsi_transport_fc.h
+++ b/include/scsi/scsi_transport_fc.h
@@ -303,6 +303,7 @@ struct fc_host_attrs {
 	/* Fixed Attributes */
 	u64 node_name;
 	u64 port_name;
+	u64 physical_port_name;
 	u32 supported_classes;
 	u8  supported_fc4s[FC_FC4_LIST_SIZE];
 	char symbolic_name[FC_SYMBOLIC_NAME_SIZE];
@@ -312,6 +313,7 @@ struct fc_host_attrs {
 
 	/* Dynamic Attributes */
 	u32 port_id;
+	u32 physical_port_id;
 	enum fc_port_type port_type;
 	enum fc_port_state port_state;
 	u8  active_fc4s[FC_FC4_LIST_SIZE];
@@ -338,6 +340,8 @@ struct fc_host_attrs {
 	(((struct fc_host_attrs *)(x)->shost_data)->node_name)
 #define fc_host_port_name(x)	\
 	(((struct fc_host_attrs *)(x)->shost_data)->port_name)
+#define fc_host_physical_port_name(x)	\
+	(((struct fc_host_attrs *)(x)->shost_data)->physical_port_name)
 #define fc_host_supported_classes(x)	\
 	(((struct fc_host_attrs *)(x)->shost_data)->supported_classes)
 #define fc_host_supported_fc4s(x)	\
@@ -352,6 +356,8 @@ struct fc_host_attrs {
 	(((struct fc_host_attrs *)(x)->shost_data)->serial_number)
 #define fc_host_port_id(x)	\
 	(((struct fc_host_attrs *)(x)->shost_data)->port_id)
+#define fc_host_physical_port_id(x)	\
+	(((struct fc_host_attrs *)(x)->shost_data)->physical_port_id)
 #define fc_host_port_type(x)	\
 	(((struct fc_host_attrs *)(x)->shost_data)->port_type)
 #define fc_host_port_state(x)	\
@@ -388,6 +394,7 @@ struct fc_function_template {
 	void 	(*get_starget_port_id)(struct scsi_target *);
 
 	void 	(*get_host_port_id)(struct Scsi_Host *);
+	void 	(*get_host_physical_port_id)(struct Scsi_Host *);
 	void	(*get_host_port_type)(struct Scsi_Host *);
 	void	(*get_host_port_state)(struct Scsi_Host *);
 	void	(*get_host_active_fc4s)(struct Scsi_Host *);
@@ -426,6 +433,7 @@ struct fc_function_template {
 	/* host fixed attributes */
 	unsigned long	show_host_node_name:1;
 	unsigned long	show_host_port_name:1;
+	unsigned long	show_host_physical_port_name:1;
 	unsigned long	show_host_supported_classes:1;
 	unsigned long	show_host_supported_fc4s:1;
 	unsigned long	show_host_symbolic_name:1;
@@ -434,6 +442,7 @@ struct fc_function_template {
 	unsigned long	show_host_serial_number:1;
 	/* host dynamic attributes */
 	unsigned long	show_host_port_id:1;
+	unsigned long	show_host_physical_port_id:1;
 	unsigned long	show_host_port_type:1;
 	unsigned long	show_host_port_state:1;
 	unsigned long	show_host_active_fc4s:1;
-- 
0.99.9n-g58e3

Re: [PATCH] fc transport: new attributes for NPIV

[James Smart]

Andreas,

I'd prefer that you do the following for NPIV...

Drop the physical_port_id attribute. I'm assuming that each virtual
port shows up as a unique scsi_host, as the FC ports and SCSI views it
has is unique to it's FC address (N_Port_ID).  As such, the
physical_port_id would be redundant with the port_id on the scsi_host
that corresponds to the physical port. Rather than determine the
relationship through scsi_host attributes, you would determine the
relationship via multiple scsi_host children under the pci adapter under
the device tree.  Obviously, if you don't buy into the scsi_host per
port_id relationship, things change and we should talk further.

As for physical_port_name, minimally, this should be changed to
primary_port_name, per the standards terms. However, as this is
meaningful only to a FC/NPIV savvy person - it may be better to simply
have an attribute such as virtual_port=<true/false>. If false, then PPN
is the port_name. If true, then you would use the same device tree
relationship pointed out above to find out which of the peers to the
scsi_host has virtual_port=true, then you have it's port_name, port_id,
etc...  Yes, it feels like a little more work, but I feel it's a better
alternative as the spread of object information internally is limited,
and the external view, which can be easily managed via scripts/tools has
as much or more information available.

-- james s


Andreas Herrmann wrote:
> From: Andreas Herrmann <aherrman@de.ibm.com>
> 
> [PATCH] fc transport: new attributes for NPIV
> 
> With NPort-Id-Virtualization (NPIV) "virtual" ports can be
> registered at an FC switch using one physical FC port.
> Using FDISC an already logged in port can login additional
> ports to the Fabric. Each addtional port gets assigned a
> new destination ID (see FDISC description in FC-FS).
> For problem determination it is useful to know not only the
> virtual port name and its associated port id but also the
> port name and port id of the physical port - the port that
> initially logged into the Fabric.
> 
> I suggest to add new attributes (physical_port_name and
> physical_port_id) to scsi_transport_fc.
> 
> Signed-off-by: Andreas Herrmann <aherrman@de.ibm.com>
> 
> ---
> 
>  drivers/scsi/scsi_transport_fc.c |    7 +++++++
>  include/scsi/scsi_transport_fc.h |    9 +++++++++
>  2 files changed, 16 insertions(+), 0 deletions(-)
> 
> 8f1f64a50977add786fdd14a0cbc13aae4bfa89f
> diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
> index 685b997..365529a 100644
> --- a/drivers/scsi/scsi_transport_fc.c
> +++ b/drivers/scsi/scsi_transport_fc.c
> @@ -295,6 +295,7 @@ static int fc_host_setup(struct transpor
>  	 */
>  	fc_host_node_name(shost) = -1;
>  	fc_host_port_name(shost) = -1;
> +	fc_host_physical_port_name(shost) = -1;
>  	fc_host_supported_classes(shost) = FC_COS_UNSPECIFIED;
>  	memset(fc_host_supported_fc4s(shost), 0,
>  		sizeof(fc_host_supported_fc4s(shost)));
> @@ -306,6 +307,7 @@ static int fc_host_setup(struct transpor
>  		sizeof(fc_host_serial_number(shost)));
>  
>  	fc_host_port_id(shost) = -1;
> +	fc_host_physical_port_id(shost) = -1;
>  	fc_host_port_type(shost) = FC_PORTTYPE_UNKNOWN;
>  	fc_host_port_state(shost) = FC_PORTSTATE_UNKNOWN;
>  	memset(fc_host_active_fc4s(shost), 0,
> @@ -795,6 +797,8 @@ static FC_CLASS_DEVICE_ATTR(host, suppor
>  
>  fc_private_host_rd_attr_cast(node_name, "0x%llx\n", 20, unsigned long long);
>  fc_private_host_rd_attr_cast(port_name, "0x%llx\n", 20, unsigned long long);
> +fc_private_host_rd_attr_cast(physical_port_name, "0x%llx\n", 20,
> +			     unsigned long long);
>  fc_private_host_rd_attr(symbolic_name, "%s\n", (FC_SYMBOLIC_NAME_SIZE +1));
>  fc_private_host_rd_attr(maxframe_size, "%u bytes\n", 20);
>  fc_private_host_rd_attr(serial_number, "%s\n", (FC_SERIAL_NUMBER_SIZE +1));
> @@ -835,6 +839,7 @@ static FC_CLASS_DEVICE_ATTR(host, speed,
>  
>  
>  fc_host_rd_attr(port_id, "0x%06x\n", 20);
> +fc_host_rd_attr(physical_port_id, "0x%06x\n", 20);
>  fc_host_rd_enum_attr(port_type, FC_PORTTYPE_MAX_NAMELEN);
>  fc_host_rd_enum_attr(port_state, FC_PORTSTATE_MAX_NAMELEN);
>  fc_host_rd_attr_cast(fabric_name, "0x%llx\n", 20, unsigned long long);
> @@ -1160,6 +1165,7 @@ fc_attach_transport(struct fc_function_t
>  	count=0;
>  	SETUP_HOST_ATTRIBUTE_RD(node_name);
>  	SETUP_HOST_ATTRIBUTE_RD(port_name);
> +	SETUP_HOST_ATTRIBUTE_RD(physical_port_name);
>  	SETUP_HOST_ATTRIBUTE_RD(supported_classes);
>  	SETUP_HOST_ATTRIBUTE_RD(supported_fc4s);
>  	SETUP_HOST_ATTRIBUTE_RD(symbolic_name);
> @@ -1168,6 +1174,7 @@ fc_attach_transport(struct fc_function_t
>  	SETUP_HOST_ATTRIBUTE_RD(serial_number);
>  
>  	SETUP_HOST_ATTRIBUTE_RD(port_id);
> +	SETUP_HOST_ATTRIBUTE_RD(physical_port_id);
>  	SETUP_HOST_ATTRIBUTE_RD(port_type);
>  	SETUP_HOST_ATTRIBUTE_RD(port_state);
>  	SETUP_HOST_ATTRIBUTE_RD(active_fc4s);
> diff --git a/include/scsi/scsi_transport_fc.h b/include/scsi/scsi_transport_fc.h
> index 394f14a..13a8171 100644
> --- a/include/scsi/scsi_transport_fc.h
> +++ b/include/scsi/scsi_transport_fc.h
> @@ -303,6 +303,7 @@ struct fc_host_attrs {
>  	/* Fixed Attributes */
>  	u64 node_name;
>  	u64 port_name;
> +	u64 physical_port_name;
>  	u32 supported_classes;
>  	u8  supported_fc4s[FC_FC4_LIST_SIZE];
>  	char symbolic_name[FC_SYMBOLIC_NAME_SIZE];
> @@ -312,6 +313,7 @@ struct fc_host_attrs {
>  
>  	/* Dynamic Attributes */
>  	u32 port_id;
> +	u32 physical_port_id;
>  	enum fc_port_type port_type;
>  	enum fc_port_state port_state;
>  	u8  active_fc4s[FC_FC4_LIST_SIZE];
> @@ -338,6 +340,8 @@ struct fc_host_attrs {
>  	(((struct fc_host_attrs *)(x)->shost_data)->node_name)
>  #define fc_host_port_name(x)	\
>  	(((struct fc_host_attrs *)(x)->shost_data)->port_name)
> +#define fc_host_physical_port_name(x)	\
> +	(((struct fc_host_attrs *)(x)->shost_data)->physical_port_name)
>  #define fc_host_supported_classes(x)	\
>  	(((struct fc_host_attrs *)(x)->shost_data)->supported_classes)
>  #define fc_host_supported_fc4s(x)	\
> @@ -352,6 +356,8 @@ struct fc_host_attrs {
>  	(((struct fc_host_attrs *)(x)->shost_data)->serial_number)
>  #define fc_host_port_id(x)	\
>  	(((struct fc_host_attrs *)(x)->shost_data)->port_id)
> +#define fc_host_physical_port_id(x)	\
> +	(((struct fc_host_attrs *)(x)->shost_data)->physical_port_id)
>  #define fc_host_port_type(x)	\
>  	(((struct fc_host_attrs *)(x)->shost_data)->port_type)
>  #define fc_host_port_state(x)	\
> @@ -388,6 +394,7 @@ struct fc_function_template {
>  	void 	(*get_starget_port_id)(struct scsi_target *);
>  
>  	void 	(*get_host_port_id)(struct Scsi_Host *);
> +	void 	(*get_host_physical_port_id)(struct Scsi_Host *);
>  	void	(*get_host_port_type)(struct Scsi_Host *);
>  	void	(*get_host_port_state)(struct Scsi_Host *);
>  	void	(*get_host_active_fc4s)(struct Scsi_Host *);
> @@ -426,6 +433,7 @@ struct fc_function_template {
>  	/* host fixed attributes */
>  	unsigned long	show_host_node_name:1;
>  	unsigned long	show_host_port_name:1;
> +	unsigned long	show_host_physical_port_name:1;
>  	unsigned long	show_host_supported_classes:1;
>  	unsigned long	show_host_supported_fc4s:1;
>  	unsigned long	show_host_symbolic_name:1;
> @@ -434,6 +442,7 @@ struct fc_function_template {
>  	unsigned long	show_host_serial_number:1;
>  	/* host dynamic attributes */
>  	unsigned long	show_host_port_id:1;
> +	unsigned long	show_host_physical_port_id:1;
>  	unsigned long	show_host_port_type:1;
>  	unsigned long	show_host_port_state:1;
>  	unsigned long	show_host_active_fc4s:1;

Re: [PATCH] fc transport: new attributes for NPIV

[Andreas Herrmann]

On 05.01.2006 15:08 James Smart <James.Smart@Emulex.Com> wrote:
> Drop the physical_port_id attribute. I'm assuming that each virtual
> port shows up as a unique scsi_host, as the FC ports and SCSI views it
> has is unique to it's FC address (N_Port_ID).  As such, the
> physical_port_id would be redundant with the port_id on the scsi_host
> that corresponds to the physical port. Rather than determine the
> relationship through scsi_host attributes, you would determine the
> relationship via multiple scsi_host children under the pci adapter under
> the device tree.  Obviously, if you don't buy into the scsi_host per
> port_id relationship, things change and we should talk further.

This all sounds sensible and I agree.
Problem is that on the mainframe I don't have access to the primary
port. Virtualization is done in adapter microcode. I just have
access to the virtual port. Hence the primary port does not show up
as a scsi_host. I cannot directly send any commands via the primary
port. I just can get some information about the primary port
(i.e. WWPN/N_Port_ID). This information I like to display in sysfs
for troubleshooting purposes. (E.g. To check whether the primary port
shows up on the switch.)

Seems that requirements for workstations and mainframes are
contrary.

> As for physical_port_name, minimally, this should be changed to
> primary_port_name, per the standards terms. However, as this is
> meaningful only to a FC/NPIV savvy person - it may be better to simply
> have an attribute such as virtual_port=<true/false>. If false, then PPN
> is the port_name. If true, then you would use the same device tree
> relationship pointed out above to find out which of the peers to the
> scsi_host has virtual_port=true, then you have it's port_name, port_id,
> etc...  Yes, it feels like a little more work, but I feel it's a better
> alternative as the spread of object information internally is limited,
> and the external view, which can be easily managed via scripts/tools has
> as much or more information available.

Again, fine with me, but due to the "flat" view of virtual adapters on
Linux on zSeries I see problems to implement this.

Only way to implement an hierarchical view for zfcp is to introduce a
"dummy" scsi_host for the primary port ... Ouch

Have to think about this for a while.


Regards,

Andreas