Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EDK2 doesn't properly support secondary HFI associations #29

Open
mwilck opened this issue Jan 11, 2024 · 1 comment
Open

EDK2 doesn't properly support secondary HFI associations #29

mwilck opened this issue Jan 11, 2024 · 1 comment

Comments

@mwilck
Copy link

mwilck commented Jan 11, 2024

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 tbzatek/libnvme#1 as an update to @tbzatek's linux-nvme/libnvme#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
Copy link
Author

mwilck commented Jan 11, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant