mbox series

[v2,00/11] zfcp: retrieve local RDP data, fix and cleanup

Message ID cover.1571934247.git.bblock@linux.ibm.com (mailing list archive)
Headers show
Series zfcp: retrieve local RDP data, fix and cleanup | expand

Message

Benjamin Block Oct. 25, 2019, 4:12 p.m. UTC
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

Comments

Martin K. Petersen Oct. 29, 2019, 2:16 a.m. UTC | #1
Benjamin,

> 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:

Applied to 5.5/scsi-queue, thanks!
Benjamin Block Oct. 29, 2019, 2:37 p.m. UTC | #2
On Mon, Oct 28, 2019 at 10:16:44PM -0400, Martin K. Petersen wrote:
> 
> Benjamin,
> 
> > 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:
> 
> Applied to 5.5/scsi-queue, thanks!
> 

Thanks, Martin.