Andreas Herrmann wrote:
Adding statistics reset callback for FC transport
Now lpfc is the second FC driver that stores old stats data in
order to reset FC host stats. (zfcp is the other one.)
Shouldn't this stuff be moved into scsi_transport_fc?
So the default for scsi_transport_fc would be to store
a stats-offset (as you call it) together with seconds since
last reset. So every FC lldd gets the reset-stats functionality
for free.
Of course an lldd is able to register its own reset-callback
(maybe because the reset is implemented in hardware)
to replace the default handler.
This just came into my mind when reviewing your patch.
In looking at what could be different:
- the handling of the "seconds from last reset" is common and could/should
go into the transport.
- I don't know that i'd change the stats data though...
I assume you are wanting to move the stats data from a LLD struct to a
transport struct: I shied away from this initially, as I allowed for
the data structure to be "hot" - e.g. the LLD is updating values in the
fast path. There are better cacheline attributes if you let the driver
manage it's own structure. Thus the call from the transport to fill in
a reported structure. Granted, for lpfc (at least) much of the LLD
data is passive as the hardware does the "hot" work.
Another reason - I shy away from the driver reaching directly into
transport structures to change values, in order to avoid race conditions.
I've tried to only do this on static data, so the access is only at
creation.
I'll look into posting a patch for the "seconds from last reset".
However, I would approach it that for now, the lpfc patches go in as is.
Then, the patch would add the transport support and update the drivers
accordingly (lpfc & zfcp included).
-- james s
-
: 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
