Re: efinet SNP issue affects iscsi boot

Re: efinet SNP issue affects iscsi boot

[Micah Parrish]

On Thu, Sep 27, 2018 at 06:15:45PM +0800, Michael Chang wrote:

> 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!

>
>> 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 ?

Its buried in a big tarball. 
https://www.oracle.com/technetwork/opensource/systems-solaris-1562786.html

It is in the part1 source code tarball, under osnet/usr/src/grub/

-Micah

Re: efinet SNP issue affects iscsi boot

[Micah Parrish]

[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]



On 09/20/2018 07:47 AM, grub-devel-request@gnu.org wrote:
> On Thu, Sep 20, 2018 at 06:38:07PM +0800, Michael Chang wrote:
>> On Thu, Sep 13, 2018 at 06:06:15PM -0600, Micah Parrish wrote:
>>> 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.
>>>
>>> Possible solutions I see:
>>>
>>> 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.
> 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



[-- Attachment #2: Type: text/html, Size: 3312 bytes --]

Re: efinet SNP issue affects iscsi boot

[Michael Chang]

On Thu, Sep 20, 2018 at 01:26:47PM -0600, Micah Parrish wrote:
> 
> 
> On 09/20/2018 07:47 AM, grub-devel-request@gnu.org wrote:
> > On Thu, Sep 20, 2018 at 06:38:07PM +0800, Michael Chang wrote:
> > > On Thu, Sep 13, 2018 at 06:06:15PM -0600, Micah Parrish wrote:
> > > > 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.
> > > > 
> > > > Possible solutions I see:
> > > > 
> > > > 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.
> > 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
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

efinet SNP issue affects iscsi boot

[Micah Parrish]

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.

Possible solutions I see:

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?


Micah Parrish
micah.parrish@hpe.com
Linux OS Engineer
Hewlett-Packard Enterprise

Re: efinet SNP issue affects iscsi boot

[Michael Chang]

On Thu, Sep 13, 2018 at 06:06:15PM -0600, Micah Parrish wrote:
> 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.
> 
> Possible solutions I see:
> 
> 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
> micah.parrish@hpe.com
> Linux OS Engineer
> Hewlett-Packard Enterprise
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: efinet SNP issue affects iscsi boot

[Daniel Kiper]

On Thu, Sep 20, 2018 at 06:38:07PM +0800, Michael Chang wrote:
> On Thu, Sep 13, 2018 at 06:06:15PM -0600, Micah Parrish wrote:
> > 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.
> >
> > Possible solutions I see:
> >
> > 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.

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

Re: efinet SNP issue affects iscsi boot

[Michael Chang]

On Thu, Sep 20, 2018 at 02:01:08PM +0200, Daniel Kiper wrote:
> On Thu, Sep 20, 2018 at 06:38:07PM +0800, Michael Chang wrote:
> > On Thu, Sep 13, 2018 at 06:06:15PM -0600, Micah Parrish wrote:
> > > 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.
> > >
> > > Possible solutions I see:
> > >
> > > 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.
> 
> 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.

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 <lersek@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.

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

> 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

> 
> Daniel

Re: efinet SNP issue affects iscsi boot

[Daniel Kiper]

On Thu, Sep 27, 2018 at 06:15:45PM +0800, Michael Chang wrote:
> On Thu, Sep 20, 2018 at 02:01:08PM +0200, Daniel Kiper wrote:
> > On Thu, Sep 20, 2018 at 06:38:07PM +0800, Michael Chang wrote:
> > > On Thu, Sep 13, 2018 at 06:06:15PM -0600, Micah Parrish wrote:
> > > > 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.
> > > >
> > > > Possible solutions I see:
> > > >
> > > > 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.
> >
> > 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.
>
> 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 <lersek@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.

More or less LGTM.

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

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

Will do.

Daniel