Реализация NVMe over TCP в ядре Linux и тесты протокола с TATLIN.UNIFIED

Согласен, мы это понимаем. Решение этой проблемы будет реализовано в будущем. Каким конкретно способом, в nvme cli, специальной страницей VPD или как-то иначе, сейчас оставим за скобками.

Реализация NVMe over TCP в ядре Linux и тесты протокола с TATLIN.UNIFIED

Проблема понятна. Сейчас lunID и серийный номер можно получить из страницы VPD Device identification

 sg_vpd -p di  /dev/nvme0n3 | grep "specific\|eui"
 eui.0000000000000054145290000F010000
 vendor specific: TATLIN.UNIFIED_XXXXXXXXX

lun id: eui.0000[000000000054]145290000F010000

tatlin-cli resource show block  | grep 000000000054
 R2D2_nvme_pool_res2  online R2D2_nvme_pool        1 TB                 999.99 GB 5 PB    84              naa.614529002664003c0403[000000000054] 4kn

NVME over RoCE. Примеряем на себя

По умолчанию MLNX_OFED и DOCA_OFED собираются с заглушкой (nvme-rdma dummy kernel module) вместо рабочего модуля. Для MLNX_OFED проблема решается ключом --with-nvmf

Один на 150 миллионов операций. Расследуем причины выброса времени отклика в операциях ввода-вывода

USE это верный подход. Но, как ни странно, по умолчанию ql2xextended_error_logging = 0, а для регистрации check condition со стороны инициатора необходим ql_dbg_io () + ql_dbg_buffer

...
qla2x00_handle_sense(srb_t *sp, uint8_t *sense_data, uint32_t par_sense_len,
		     uint32_t sense_len, struct rsp_que *rsp, int res)
{
	...

	if (sense_len) {
		ql_dbg(ql_dbg_io + ql_dbg_buffer, vha, 0x301c,
		    "Check condition Sense data, nexus%ld:%d:%llu cmd=%p.\n",
		    sp->vha->host_no, cp->device->id, cp->device->lun,
		    cp);
		ql_dump_buffer(ql_dbg_io + ql_dbg_buffer, vha, 0x302b,
		    cp->sense_buffer, sense_len);
	}
}
...

https://elixir.bootlin.com/linux/latest/source/drivers/scsi/qla2xxx/qla_isr.c#L3008

...
#define ql_dbg_io	0x08000000 /* IO Tracing Debug */
...
#define ql_dbg_buffer	0x00020000 /* For dumping the buffer/regs */
...

https://elixir.bootlin.com/linux/latest/source/drivers/scsi/qla2xxx/qla_dbg.h#L347

Один на 150 миллионов операций. Расследуем причины выброса времени отклика в операциях ввода-вывода

В целом подобные задачи не являются целевыми для программистов, по крайней мере на начальном этапе анализа, пока нет четкого понимания вызвано ли наблюдаемое явление нежелательным поведением кода, аппаратной платформы, либо средой, в которой производится тестирование. Когда проблема локализована, редуцирован сценарий воспроизведения, она может быть оформлена как заявка на исправление ошибки или улучшение, т.е. передана в команду разработки.

Один на 150 миллионов операций. Расследуем причины выброса времени отклика в операциях ввода-вывода

Это комплексный вопрос. Обвинять что-либо — это строить гипотезы без их подтверждения.
Необходимо собрать как можно больше данных как из окружения пользователя, так и с СХД. Чтобы реализовать первое, Вам понадобится некоторая экспертиза с Вашей стороны. Для сбора данных с СХД необходима помощь технической поддержки вендора. Естественно, скорому достижению результата способствует взаимопонимание и сотрудничество.