Re: [RFC 16/16] lpfc: vmid: Introducing vmid in io path.

James Smart
2020-08-05T23:38:32Z

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