Data Area 4 Support on Telemetry Logs

[jeff-lien-sndk]

The current nvme cli telemetry-log command does not set etdas when retrieving data are 4 of the hos telemetry log. If etdas is not set, then the dalb4 value int the telemetry log header will be 0 and no data will be collected.

My question is should the nvme telemetry code check for da4 support and set the etdas bit in feature 0x16 under the covers? Or should it be the user's responsibility to manually set the etdas bit before executing the telemetry-log command? In my opinion, I think the telemetry-log code should just set it (if da 4 is supported), collect the telemetry log, and then restore it when finished.

[igaw]

I think if 'da 4' is supported the telemetry-log should do the right thing and automatically set it. Though if I understand the situation correctly, we currently default to 3:

	const char *dgen = "Pick which telemetry data area to report. Default is 3 to fetch areas 1-3. Valid options are 1, 2, 3, 4.";

So if the user selects 4 it should do the right thing.

[jeff-lien-sndk]

Sounds good @igaw . I'll make the changes in the telemetry-log code to check for da4 support and set the ETDAS bit if supported.

[ikegami-t]

If etdas is not set, then the dalb4 value int the telemetry log header will be 0 and no data will be collected.

Is this actual the drive behavior? Seems the etdas value just for the host side support behavior so I am not sure if the drive behavior to change the behavior for etdas correct or not.

Just FYI: By the way the ETDAS bit is supported by the NVMe revision 2.0 so the drive not supported the revision is not able to set. (To make sure let me comment.)

[jeff-lien-sndk]

I noticed this behavior of "dalb4 value int the telemetry log header will be 0" with our drives when the etdas bit was not set. I think it's ok for the drive to set the dalb4 field to 0 if the etdas bit is not set. This prevents the host from calculating the wrong length of the telemetry log.

[ikegami-t]

Understood. Thank you so much for your explanation.

[igaw]

IIRC this has been addressed, right? Good to close?

[jeff-lien-sndk]

Yes, this issue was resolved with #2894. Therefore, closing this issues.