NetworkPkg/NvmeOfDxe: Resolve NBFT population issues

[trevor-cockrell]

• Adjust HFI population logic to no longer skip by MAC, instead check for a unique transport descriptor hash
• Discovery ctlr population logic no longer treats each DeviceAdapter as an individual Discovery ctlr; Discovery ctlr entries now populated based on order in which unique Disc. ctlrs were found
• Properly map SSNS, Discovery ctlrs to their respective primary HFI
• Properly map SSNS records to their respective primary Discovery ctlr

Fixes #33

[trevor-cockrell]

Addresses #34 , solution should also replace #33.

[tbzatek]

Retested with clean efivars, I think I might have messed up my env. last time.

Fixed:

• 33 - all SSNS -> HFI indexes are correct
• 34 base scenario - both Discovery Descriptors present, correct SSNS -> DD indexes
• 34 the second bad scenario - the second boot attempt pointing to an invalid IP address
  • both Discovery Descriptors present, the last SSNS record points to the second HFI and the second Discovery Descriptor

Still an issue:

• 34 first bad scenario - the first boot attempt pointing to an invalid IP address
  • only one Discovery Descriptor and the HFI record for the (good) second boot attempt present
  • no extra SSNS record like in the opposite scenario, i.e. the first boot attempt is not reflected in the NBFT table in any way (no HFI, no Discovery, no SSNS corresponding records)
  • NBFT table attached: NBFT.gz

[mwilck]

Looks good to me. I didn't have time to do actual testing yet.

[trevor-cockrell]

Still an issue: 34 first bad scenario - the first boot attempt pointing to an invalid IP address

@tbzatek I'm having trouble reproducing this issue on this branch with a clean build.
If I configure Attempt 1 with an invalid address and Attempt 2 with a valid target config, I still see HFI + SSNS + Discovery entries for the failed attempt.
Can you share more on your attempt configuration -- are the target addresses the only different items between the two?

[tbzatek]

So the only thing I've changed in this scenario was the target IP address in Attempt 1. There's no gateway and the IP address is simply unreachable on the network.

This results in nvme_nbft_show.json

Looks like there's a difference between "interface link down" and "interface up but unreachable target" scenarios.

[johnmeneghini]

Let's open a new issue to track the unfixed issues and merge this.

Still an issue:

34 first bad scenario - the first boot attempt pointing to an invalid IP address
only one Discovery Descriptor and the HFI record for the (good) second boot attempt present
no extra SSNS record like in the opposite scenario, i.e. the first boot attempt is not reflected in the NBFT table in any way (no HFI, no Discovery, no SSNS corresponding records)
NBFT table attached: NBFT.gz