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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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


-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux