efinet SNP issue affects iscsi boot

Hi, new subscriber here. We have a problem with Grub 2 and its use of SNP
instead of MNP. Our UEFI driver for a network card parses the relevant DHCP
options for iSCSI boot, generates an iBFT table, then gets closed by Grub
when it opens the SNP interface. The driver removes the iBFT table as part
of normal unload cleanup. I think this should happen with the Tianocore
UEFI reference driver as well. The problem is often masked or does not
occur when there are multiple network ports enabled. It occurs with several
different vendors NICs.
1. Grub parses the DHCP options and creates its own iBFT.
2. Grub copies the already generated iBFT before destroying the interface.
3. Grub opens the network interface MNP instead of SNP.
Although I am a neophyte at grub and UEFI development, I would like to start
a discussion on possible solutions. Has anyone else seen this?

For possible solution 3, I managed to work out patch to use MNP but is not
polished, although it survived my testing. If you don't mind and willing to
give it go I will post it here as RFC patch for review.

Thanks,
Michael

Micah Parrish
Linux OS Engineer
Hewlett-Packard Enterprise
_______________________________________________
Grub-devel mailing list
https://lists.gnu.org/mailman/listinfo/grub-devel

Daniel Kiper

2018-09-20 12:01:08 UTC

Hi, new subscriber here.? We have a problem with Grub 2 and its use of SNP
instead of MNP.? Our UEFI driver for a network card parses the relevant DHCP
options for iSCSI boot, generates an iBFT table, then gets closed by Grub
when it opens the SNP interface. The driver removes the iBFT table as part
of normal unload cleanup.? I think this should happen with the Tianocore
UEFI reference driver as well.? The problem is often masked or does not
occur when there are multiple network ports enabled.? It occurs with several
different vendors NICs.
1. Grub parses the DHCP options and creates its own iBFT.
2. Grub copies the already generated iBFT before destroying the interface.
3. Grub opens the network interface MNP instead of SNP.
Although I am a neophyte at grub and UEFI development, I would like to start
a discussion on possible solutions.? Has anyone else seen this?

That would be perfect. However, there are a few things worth mentioning here.

The issue is never ending story. So, please look for relevant discussions
in grub-devel archives and take them into account if it is possible/make sense.
If you have any difficulties with finding them drop me a line.

Please do not drop SNP driver. I think that we should make MNP driver a new
default and SNP should stay as a backup. Just in case.

Additionally, a few days ago I have started looking for people interested
in the project. There are some. Hence, if you are going to take a stab at
it I will ask them to do some reviews of your work. I will drop you their
emails if they are happy to do so.

Daniel

Michael Chang

2018-09-27 10:15:45 UTC

Thanks. I'm able to find those discussions in my mailbox. They are indeed very
helpful for me in catching up the problems.

Moreover I found that Laszlo Ersek <***@redhat.com> already proposed an
approach which is very close to what I was working on,

- identify NIC handles the same way you do now (I guess by enumerating
SNP interfaces)
- for each handle found, look for MNPSB *first*.
- If there is no MNPSB, then stick with the current strategy -- open
the SNP with exclusive access
- However, if there *is* an MNPSB, call the CreateChild() function to
extract a new MNP instance
- Use this MNP instance to send and receive packets. This MNP instance
will peacefully coexist with other (sibling) MNP clients.

Post by Daniel Kiper
Please do not drop SNP driver. I think that we should make MNP driver a new
default and SNP should stay as a backup. Just in case.

Yes. The patch has been worked the way you asked.

Post by Daniel Kiper
Additionally, a few days ago I have started looking for people interested
in the project. There are some. Hence, if you are going to take a stab at
it I will ask them to do some reviews of your work. I will drop you their
emails if they are happy to do so.

Please feel free to CC them to the discussion.

Thanks,
Michael

Post by Daniel Kiper
Daniel

Daniel Kiper

2018-09-27 16:29:20 UTC

Thanks. I'm able to find those discussions in my mailbox. They are indeed very
helpful for me in catching up the problems.
approach which is very close to what I was working on,
- identify NIC handles the same way you do now (I guess by enumerating
SNP interfaces)
- for each handle found, look for MNPSB *first*.
- If there is no MNPSB, then stick with the current strategy -- open
the SNP with exclusive access
- However, if there *is* an MNPSB, call the CreateChild() function to
extract a new MNP instance
- Use this MNP instance to send and receive packets. This MNP instance
will peacefully coexist with other (sibling) MNP clients.

More or less LGTM.

Post by Daniel Kiper
Please do not drop SNP driver. I think that we should make MNP driver a new
default and SNP should stay as a backup. Just in case.

Yes. The patch has been worked the way you asked.

I will try to take a look at it next week.

Please feel free to CC them to the discussion.

Will do.

Daniel

Micah Parrish

2018-09-20 19:26:47 UTC

That would be perfect. However, there are a few things worth mentioning here.
The issue is never ending story. So, please look for relevant discussions
in grub-devel archives and take them into account if it is possible/make sense.
If you have any difficulties with finding them drop me a line.
Please do not drop SNP driver. I think that we should make MNP driver a new
default and SNP should stay as a backup. Just in case.
Additionally, a few days ago I have started looking for people interested
in the project. There are some. Hence, if you are going to take a stab at
it I will ask them to do some reviews of your work. I will drop you their
emails if they are happy to do so.

Thank you for the context.Â I read through the archives, searching for
SNP.Â I'm willing to test whatever we come up with.

I also read through the efinet.c from OpenSolaris.Â It is quite
different from the current SNP efinet.c, since it uses a ring buffer and
filters.Â I assume a naive switch over to MNP might run into the same
lost packet problem seen before.Â Was it seen across many platforms, or
specific to a few?

-Micah

Michael Chang

2018-09-27 10:22:47 UTC

That would be perfect. However, there are a few things worth mentioning here.
The issue is never ending story. So, please look for relevant discussions
in grub-devel archives and take them into account if it is possible/make sense.
If you have any difficulties with finding them drop me a line.
Please do not drop SNP driver. I think that we should make MNP driver a new
default and SNP should stay as a backup. Just in case.
Additionally, a few days ago I have started looking for people interested
in the project. There are some. Hence, if you are going to take a stab at
it I will ask them to do some reviews of your work. I will drop you their
emails if they are happy to do so.

Thank you for the context. I read through the archives, searching for SNP.
I'm willing to test whatever we come up with.

I have posted the RFC patch to the list. If you don't see it please let me know.

I also read through the efinet.c from OpenSolaris. It is quite different
from the current SNP efinet.c, since it uses a ring buffer and filters. I
assume a naive switch over to MNP might run into the same lost packet
problem seen before. Was it seen across many platforms, or specific to a
few?

I did not experience any packet loss problem. But neverthelast I would like to
have a look on the OpenSolaris patch. Where can I find it ?

Thanks,
Michael

-Micah
_______________________________________________
Grub-devel mailing list
https://lists.gnu.org/mailman/listinfo/grub-devel

Micah Parrish

2018-09-27 18:58:02 UTC

Post by Michael Chang
I have posted the RFC patch to the list. If you don't see it please let me know.

I will give it a try, thanks!