On 4/20/2021 5:38 AM, Benjamin Block wrote:
...
+ len = *((u32 *)(pcmd + 4));
+ len = be32_to_cpu(len);
+ memcpy(vport->qfpa_res, pcmd, len + 8);
+ len = len / LPFC_PRIORITY_RANGE_DESC_SIZE;
+
+ desc = (struct priority_range_desc *)(pcmd + 8);
+ vmid_range = vport->vmid_priority.vmid_range;
+ if (!vmid_range) {
+ vmid_range = kcalloc(MAX_PRIORITY_DESC, sizeof(*vmid_range),
+ GFP_KERNEL);
+ if (!vmid_range) {
+ kfree(vport->qfpa_res);
+ goto out;
+ }
+ vport->vmid_priority.vmid_range = vmid_range;
+ }
+ vport->vmid_priority.num_descriptors = len;
+
+ for (i = 0; i < len; i++, vmid_range++, desc++) {
+ lpfc_printf_vlog(vport, KERN_DEBUG, LOG_ELS,
+ "6539 vmid values low=%d, high=%d, qos=%d, "
+ "local ve id=%d\n", desc->lo_range,
+ desc->hi_range, desc->qos_priority,
+ desc->local_ve_id);
+
+ vmid_range->low = desc->lo_range << 1;
+ if (desc->local_ve_id == QFPA_ODD_ONLY)
+ vmid_range->low++;
+ if (desc->qos_priority)
+ vport->vmid_flag |= LPFC_VMID_QOS_ENABLED;
+ vmid_range->qos = desc->qos_priority;
I'm curios, if the FC-switch signals it supports QoS for a range here, how
exactly interacts this with the VM IDs that you seem to allocate
dynamically during runtime for cgroups that request specific App IDs?
You don't seem to use `LPFC_VMID_QOS_ENABLED` anywhere else in the
series. >
Would different cgroups get different QoS classes/guarantees depending
on the selected VM ID (higher VM ID gets better QoS class, or something
like that?)? Would the tagged traffic be handled differently than the
ordinary traffic in the fabric?
The simple answer is there is no interaction w/ the cgroup on priority.
And no- we really don't look or use it. The ranges don't really have
hard priority values. The way it works is that all values within a range
is equal; a value in the first range is "higher priority" than a value
in the second range; and a value in the second range is higher than
those in the third range, and so on. Doesn't really matter whether the
range was marked Best Effort or H/M/L. There's no real "weight".
What you see is the driver simply recording the different ranges so that
it knows what to allocate from later on. The driver creates a flat
bitmap of all possible values (max of 255) from all ranges - then will
allocate values on a first bit set basis. I know at one point we were
going to only auto-assign if there was 1 range, and if multiple range
was going to defer a mgmt authority to tell us which range, but this
obviously doesn't do that.
Also... although this is coded to support the full breadth of what the
standard allows, it may well be the switch only implements 1 range in
practice.
I tried to get something from FC-LS (-5) or FC-FS (-6), but they are extremely
sparse somehow. FC-LS-5 just says "QoS priority provided" for the
field.. and FC-FS doesn't say anything regarding QoS if the tagging
extension in CS_CTL is used.
Yes - most of the discussion on how this form of VMID is used/performed
was given in the T11 proposals, but as most of that is informational and
non-normative, very little ends up getting into the spec.
FC-LS-5 section 9 "Priority Tagging" is what you want to look at.
The other form of VMID is the Application Tag (up to 32bits) which is
described in FC-GS-8 section 6.9 Application Server. Both forms map a
value to a uuid and the switch may apply some QoS level to the value
when it sees it.
The priority tagging method seems to tie in more to qos, but the
application tag is can equally be done although any qos aspects are
solely in the switch and not exported to the driver/host.
-- james
