ocp: Statistic Area offsets not handled as zero‑based per OCP 2.5 (09282023), 2.6, and 2.7 specifications

[sfindley102892]

I want to confirm whether the ocp telemetry parser is expected to support OCP 2.6 / 2.7 fields.

From reviewing the current implementation, it seems the telemetry decode logic is based on the OCP 2.5r9 interpretation of the TELDF-13, TELDF-15 Statistic Area requirements ref: #2354. However, with OCP 2.5 (09282023), the spec says that TELDF Statistic Area fields are zero‑based offsets. This requirement continues into OCP 2.6 and 2.7.

In the current telemetry‑decoder code, the offsets are not treated as zero‑based values. Examples from plugins/ocp/ocp-telemetry-decode.c

// Data is present in the form of DWORDS, so multiplying with sizeof(DWORD)
stats_da_1_start_dw = (stats_da_1_start * SIZE_OF_DWORD);
stats_da_1_size_dw  = (stats_da_1_size  * SIZE_OF_DWORD);

stats_da_2_start_dw = (stats_da_2_start * SIZE_OF_DWORD);
stats_da_2_size_dw  = (stats_da_2_size  * SIZE_OF_DWORD);

According to OCP 2.5 (09282023) 2.6 and 2.7, these fields should be interpreted as zero‑based, but the decoder currently appears to apply the 2.5 rule set.

Questions:

1. Is the telemetry parser expected to support OCP 2.6 / 2.7 compliance?
2. If yes, is there a plan or timeline to update telemetry‑decoder handling of TELDF to use zero‑based offsets?
3. If no, should we consider adding a version‑based decode path or updating these offset calculations?

References:

• https://www.opencompute.org/documents/datacenter-nvme-ssd-specification-v2-5-pdf
• https://www.opencompute.org/documents/datacenter-nvme-ssd-specification-v2-6-2-pdf

[igaw]

Disclaimer, I don't really work on the ocp plugin. So I don't think I am the one who should decide anything.

Anyway, there were similar cases, where a newer version of the specification changed the meaning of a field. And the solution was to introduce a command line option to switch between the different versions.

	/*
	 * Different spec versions ask for different nsid values
	 * OCP v1.0 - NSID: Shall be set to zero
	 * OCP v2.0r21 - NSID: Shall be set to FFFFFFFFh.
	 * OCP v2.5 - NSID: The host should either clear this to zero or set this to FFFFFFFFh
	 */
	nsid = argconfig_parse_seen(opts, "all-ns") ? NVME_NSID_ALL : 0;

or

	if (!argconfig_parse_seen(opts, "no-uuid")) {
		/* OCP 2.0 requires UUID index support */
		err = ocp_get_uuid_index(hdl, &uidx);
		if (err || !uidx) {
			nvme_show_error("ERROR: No OCP UUID index found");
			return err;
		}
	}

Ideally the spec version could be detected and the quirks autoselected.

To your question:

1. I suppose the plugin should support the latest greatest. At least this is what is done for the NVMe spec (though this one doesn't seem to get so many incompatible changes).
2. I wont work on this plugin, so I can't say anything.
3. Yes, please. It's an open source project after all :) So I am glad to get PRs

Adding some folks who have done some work on the plugin lately. They might have something to say. @ikegami-t @brandon-paupore-sndk @jeff-lien-sndk @VigneshwaranSaravana @saskchaithanya

[ikegami-t]

In the current telemetry‑decoder code, the offsets are not treated as zero‑based values. Examples from plugins/ocp/ocp-telemetry-decode.c

How can I confirm as the offsets are not treated as zero-based values? Can you show the detail information? Since I check the examples and the current implementation and the older version specification. Note: The older version specification described as below as it is not desribed as the zero-based but clearly described as the offset so looks as the zero-based value in the older version documentation also as same.

By the way seems the ocp command just displays the drive data itself as decoded then the drive data is not zero-based I think.

[jeff-lien-sndk]

Both the OCP 2.5 and 2.6 spec's mention that t the Data Area 1 and 2 Statistic Start fields "shall contain a zero-based value". I haven't seen the 2.7 version - is it even available? If version 2.7 is available, has it changed?

I'm not sure what the question here is. Is there concerns that the current telemetry decoding implementation is not correct? Or has the OCP 2.7 spec changed and now requires an update to the ocp plugin telemetry decoder?

[rskeeble-sd]

(OCP 2.6)
I wonder if the requirement that statistic data start offsets be zero-based is an editing oversight? FIFO data start offsets are not zero-based. Why should the spec have two different notions of start offset within the same block of data, the DA1 header?
Furthermore, the spec allows for any order of statistics data and FIFO data in a data area, but the requirement for statistics data start offset will not allow placing that data at offset zero in the data area.

Stats requirement:

FIFO requirement:

Data area order:

[ikegami-t]

Seems This field hsall contain a zero-based value. means just the field value started from zero since it is just an offset value. Then both TELDF-15 and TELDF-34 are offset values as started from the zero value. Also the older version OCP 2.5r9 specification is same for this.

[jeff-lien-sndk]

Thanks to @brandon-paupore-sndk for tracking down the OCP 2.7 Spec. Here's the link:
https://www.opencompute.org/documents/datacenter-nvme-ssd-specification-v2-7-final-pdf-1

There's no change in the wording for the TELDF-13 and 15 fields in that version as well. I do agree it seems like could be an editing oversite.