search

timberland-sig / edk2

EDK II fork for Timberland-SIG POC
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
Other
3 stars 2 forks source link

EDK2 doesn't properly support secondary HFI associations #29

Open mwilck opened 10 months ago

mwilck commented 10 months ago

As shown in this comment, the Timberland EDK2 code doesn't properly support the "secondary HFI associations" field of the SSNS record.

The current code always creates a 1-element array in the secondary HFI associations object, duplicating value the "primary HFI descriptor index". This is not wrong according to the spec, but redundant and possibly confusing to applications consuming this data. I have filed https://github.com/tbzatek/libnvme/pull/1 as an update to @tbzatek's https://github.com/linux-nvme/libnvme/pull/766 to eliminate these duplicates in libnvme. But that's not the point here.

The bigger issue is that EDK2 doesn't support a real secondary HFI associations list, which wouldn't duplicate the primary HFI, but would instead add other HFI indices through which a connection to the SNSS record at hand must be attempted. Support for that would be a prerequisite to simulating boot over NVMe multipath properly.

With the current code (including @trevor-cockrell's latest PRs like #25), there can be multiple HFI records and multiple SNSS records, but there is no way to link an SNSS record to multiple HFIs. If the OS is able to bring up multiple HFIs from the NBFT, and if connection via the primary HFI fails, nvme-cli's discover_from_nbft() code will retry the connection without a source IP address, which may (or may not, depending on routing configuration) then succeed through a different HFI, giving the impression of a "multipath" setup in failover mode.

The lack of support for this feature makes it very difficult for OS developers to develop and test multipath support on the OS side.

@Douglas-Farley @tbzatek @johnmeneghini for information.

mwilck commented 10 months ago

As discussed in the current Timberland SIG call, it is currently possible to create multiple SNSS entries for the same subsystem/namespace and with a different primary HFI, which comes down to a multipath configuration, too, just without using the secondary HFI association field.

Technically, using a single SNSS entry + secondary HFI associations would be cleaner, but in terms of HII interface it would be a more complicated workflow to set up (current attempt configuration UI presents the HFI and SNSS configuration options in a single screen).