On 8/5/2020 12:16 AM, Hannes Reinecke wrote:
Well.
Creating a VMID in the hotpath with a while() loop will be bogging
down performance to no end.
I'd rather have restricted the ->queuecommand() function to a direct
lookup.
If that fails (as the VMID isn't registered) we should kicking of a
workqueue for registering the VMID and return BUSY.
Or tweak blkcg to register the VMID directly, and reject the command
if the VMID isn't registered :-)
Cheers,
Hannes
That's actually what's supposed to be happening. fastpath uses the uuid
to look up a vmid tag. If no vmid tag, kick off the fabric traffic that
will get one but don't wait for it to complete. Any io issued while that
process is occurring will be not be vmid tagged. I'll circle back on
lpfc to make sure this is happening.
In the mean time - the most important patch to review is the cgroup
patch - patch1.
If we wanted to speed the driver's io path up, one thing to consider is
adding a driver-settable value on the blkcg structure. Once the fabric
traffic obtained the vmid, the driver would set the blkcg structure with
the value. In this scenario though, as the vmid is destroyed as of link
down, the driver needs a way, independent of an io, to reach into the
blkcg struct to clear the vmid value. We also need to be sure the blkcg
struct won't be on top of a multipath device or something such that the
blkcg struct may be referenced by a different scsi host - I assume we're
good in that area.
-- james
