From: Benjamin Block <bblock@linux.ibm.com>
To: "James E . J . Bottomley" <jejb@linux.ibm.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Benjamin Block <bblock@linux.ibm.com>,
Steffen Maier <maier@linux.ibm.com>,
Jens Remus <jremus@linux.ibm.com>,
Fedor Loshakov <loshakov@linux.ibm.com>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
linux-scsi@vger.kernel.org, linux-s390@vger.kernel.org
Subject: [PATCH v2 00/11] zfcp: retrieve local RDP data, fix and cleanup
Date: Fri, 25 Oct 2019 18:12:42 +0200 [thread overview]
Message-ID: <cover.1571934247.git.bblock@linux.ibm.com> (raw)
Hello all,
this is the second version of my RDP patchset for zfcp, after I noticed
a memory-leak in the first version earlier this year. Here is the
original description, which remains valid:
With FC-LS-3 Fibre Channel got support for the RDP Extended Link
Service, which we can use to gather diagnostics data (health values
from the optics and such). To gather those data from our local link,
the FCP Channel firmware (for FCP and Ficon Express adapters) added
some new fields in our Exchange Port Data firmware command
(primarily SFP data).
This patchset adds a new sysfs-directory below our
adapter-object and several files in that to read those new fields.
Additionally this also adds a file to read the buffer-to-buffer
credit value from our local port (also something that can be
gathered using the RDP ELS).
The main purpose of the data from RDP requests (at least in my mind)
are to catch some otherwise hard to track down errors, like dirt on
the fibre and such (I would expect optics data to degraded with such
conditions). These things are a pain to track down because it
doesn't cause the link to go away, just some sporadic errors that
can result in incomplete exchanges and such.
The patchset is somewhat big because I don't want to issue a single
Exchange Port/Config Data command for each read of those files,
which would generate unnecessary traffic (and possibly inconsistent
data) on our command-queue (we don't have an admin-queue or some
such). So it also adds a (time-based) mechanism to cache data from
Exchange Config/Port Data.
We also want to prevent our adapter-structure from growing,
which would further grow Scsi_Host, which is already too damn big,
so these data are decoupled.
More details are in the patches themselves.
Additionally to this, there are two more patches from Steffen that we
want to include, the first (patch 10) is just a cleanup for better
readability, the second (patch 11) is a fix/improvement for our
tracing-feature to make traces of failed FCP requests better. Even
though Steffen flagged the later as fix, I don't think we need extra
handling for it, if it goes in with the rest, thats fine - its nothing
pressing.
Reviews are highly welcome :-).
James, Martin, if there are no objections, it would be nice if you could
still include this in the merge for 5.5.
FYI: I also plan to/am in the middle of writing a simple command-line
tool to send RDP to all/certain available remote/local FC-Ports in
the System and present them in a sane format (sane to me ;-) ).
This could be used for logging, or while gathering debug-data from
a system.
The RDP ELS' to remote ports will be send using BSG. Local data
(for zFCP) would be read using this new interface.
If anyone is interested, I can point it out on the list once I have
something that has at least a minimum set of functionality.
Benjamin Block (9):
zfcp: signal incomplete or error for sync exchange config/port data
zfcp: diagnostics buffer caching and use for exchange port data
zfcp: add diagnostics buffer for exchange config data
zfcp: support retrieval of SFP Data via Exchange Port Data
zfcp: introduce SysFS interface for diagnostics of local SFP
transceiver
zfcp: implicitly refresh port-data diagnostics when reading SysFS
zfcp: introduce SysFS interface to read the local B2B-Credit
zfcp: implicitly refresh config-data diagnostics when reading SysFS
zfcp: move maximum age of diagnostic buffers into a per-adapter
variable
Steffen Maier (2):
zfcp: proper indentation to reduce confusion in zfcp_erp_required_act
zfcp: trace channel log even for FCP command responses
drivers/s390/scsi/Makefile | 2 +-
drivers/s390/scsi/zfcp_aux.c | 12 +-
drivers/s390/scsi/zfcp_dbf.c | 8 +-
drivers/s390/scsi/zfcp_def.h | 4 +-
drivers/s390/scsi/zfcp_diag.c | 305 +++++++++++++++++++++++++++++++++
drivers/s390/scsi/zfcp_diag.h | 101 +++++++++++
drivers/s390/scsi/zfcp_erp.c | 4 +-
drivers/s390/scsi/zfcp_ext.h | 1 +
drivers/s390/scsi/zfcp_fsf.c | 73 +++++++-
drivers/s390/scsi/zfcp_fsf.h | 21 ++-
drivers/s390/scsi/zfcp_scsi.c | 4 +-
drivers/s390/scsi/zfcp_sysfs.c | 170 +++++++++++++++++-
12 files changed, 683 insertions(+), 22 deletions(-)
create mode 100644 drivers/s390/scsi/zfcp_diag.c
create mode 100644 drivers/s390/scsi/zfcp_diag.h
--
2.21.0
next reply other threads:[~2019-10-25 16:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-25 16:12 Benjamin Block [this message]
2019-10-25 16:12 ` [PATCH v2 01/11] zfcp: signal incomplete or error for sync exchange config/port data Benjamin Block
2019-10-25 16:12 ` [PATCH v2 02/11] zfcp: diagnostics buffer caching and use for exchange port data Benjamin Block
2019-10-25 16:12 ` [PATCH v2 03/11] zfcp: add diagnostics buffer for exchange config data Benjamin Block
2019-10-25 16:12 ` [PATCH v2 04/11] zfcp: support retrieval of SFP Data via Exchange Port Data Benjamin Block
2019-10-25 16:12 ` [PATCH v2 05/11] zfcp: introduce SysFS interface for diagnostics of local SFP transceiver Benjamin Block
2019-10-25 16:12 ` [PATCH v2 06/11] zfcp: implicitly refresh port-data diagnostics when reading SysFS Benjamin Block
2019-10-25 16:12 ` [PATCH v2 07/11] zfcp: introduce SysFS interface to read the local B2B-Credit Benjamin Block
2019-10-25 16:12 ` [PATCH v2 08/11] zfcp: implicitly refresh config-data diagnostics when reading SysFS Benjamin Block
2019-10-25 16:12 ` [PATCH v2 09/11] zfcp: move maximum age of diagnostic buffers into a per-adapter variable Benjamin Block
2019-10-25 16:12 ` [PATCH v2 10/11] zfcp: proper indentation to reduce confusion in zfcp_erp_required_act Benjamin Block
2019-10-25 16:12 ` [PATCH v2 11/11] zfcp: trace channel log even for FCP command responses Benjamin Block
2019-10-29 2:16 ` [PATCH v2 00/11] zfcp: retrieve local RDP data, fix and cleanup Martin K. Petersen
2019-10-29 14:37 ` Benjamin Block
2019-10-29 14:37 ` Benjamin Block
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1571934247.git.bblock@linux.ibm.com \
--to=bblock@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=jejb@linux.ibm.com \
--cc=jremus@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=loshakov@linux.ibm.com \
--cc=maier@linux.ibm.com \
--cc=martin.petersen@oracle.com \
--cc=oberpar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.