From: Shyam Sundar <ssundar@marvell.com>
To: James Smart <james.smart@broadcom.com>,
Nilesh Javali <njavali@marvell.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
GR-QLogic-Storage-Upstream
<GR-QLogic-Storage-Upstream@marvell.com>
Subject: Re: [EXT] Re: [PATCH 1/2] scsi: fc: Update statistics for host and rport on FPIN reception.
Date: Wed, 30 Sep 2020 20:55:27 +0000 [thread overview]
Message-ID: <05745075-014E-4C56-AD69-8F428D658CA7@marvell.com> (raw)
In-Reply-To: <a0ace8fd-eaec-bb53-11d1-b686a90e16f4@broadcom.com>
I'm saying that we have no idea who the "detecting" port was in all of
the statistics. At least, by not counting the detecting port, we know
that anything that has counters incrementing was generating the issue.
I don't know how important it is to know the detecting port - if
switch/fabric, it probably doesn't matter. If an NxPort, it may be
interesting to know. We also have no idea if all the counter updates
occurred in 1 fpin, or in N fpins. What I was suggesting was to log
something like "FPIN <type> <detecting> <attached>", with one per
descriptor type in the FPIN. We could default this logging off, and
change a tunable to turn it on.
However, I feel like I'm trying to hard for this - so let's just ignore
it. We can always add it in the future.
Shyam; Got it. That makes sense.
I'll make a note of that and send out a patch for this separately.
>
> All the other comments make sense to me. I'll roll them in and send out another patchset shortly.
>
> Regards
> Shyam
>
>
Sounds good. Thanks
-- james
next prev parent reply other threads:[~2020-09-30 20:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-30 6:11 [PATCH 0/2] SAN Congestion Management (SCM) statistics Nilesh Javali
2020-07-30 6:11 ` [PATCH 1/2] scsi: fc: Update statistics for host and rport on FPIN reception Nilesh Javali
2020-09-09 13:51 ` Himanshu Madhani
2020-09-23 0:01 ` James Smart
2020-09-28 20:07 ` Shyam Sundar
2020-09-29 21:33 ` James Smart
2020-09-30 20:55 ` Shyam Sundar [this message]
2021-10-01 1:37 ` kernel test robot
2021-10-01 1:37 ` kernel test robot
2020-07-30 6:11 ` [PATCH 2/2] scsi: fc: Update documentation of sysfs nodes for FPIN stats Nilesh Javali
2020-09-09 13:51 ` Himanshu Madhani
2020-09-23 0:15 ` James Smart
2020-09-07 10:44 ` [PATCH 0/2] SAN Congestion Management (SCM) statistics Nilesh Javali
2020-09-09 2:57 ` Martin K. Petersen
2020-09-17 16:53 ` [EXT] " Nilesh Javali
2020-09-23 8:38 ` Hannes Reinecke
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=05745075-014E-4C56-AD69-8F428D658CA7@marvell.com \
--to=ssundar@marvell.com \
--cc=GR-QLogic-Storage-Upstream@marvell.com \
--cc=james.smart@broadcom.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=njavali@marvell.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.