[gPXE-devel] Status of staging branches, prep for gPXE 1.0.0

Marty Connor mdc at etherboot.org
Sat Jul 3 11:39:53 EDT 2010


Hi Peter,

I am revisiting this old thread because I think of these issues, and
would like to continue discussing them.

I have moved this discussion to gpxe-devel because I think that having
more people share their thoughts will help move the discussion forward
faster.

H. Peter Anvin wrote on 1/15/10 1:02 PM:
> On 01/15/2010 08:14 AM, Marty Connor wrote:
>> Does anyone (hpa? sha0?) know if there is anything we can do to
>> better integrate with pxelinux?  I know Syslinux 4.0 is coming, but
>> I'd like to do what we can to be as interoperable and featureful as
>> possible.

> 1. Initial DHCP elision for undionly.kkpxe.  The double DHCP is
> actively harmful in certain configurations, and is always redundant.

Done.
http://git.etherboot.org/?p=gpxe.git;a=commit;h=9e9cc8c60ff573e02615889a4b7fa469c42fe425

> 2. A working mechanism for chainloading another NBP for
> undionly.kkpxe.  This is the one feature which is completely missing
> from gpxelinux.0.

Done.
http://git.etherboot.org/?p=gpxe.git;a=commit;h=112a3f2de281a2afb23ced2082d555720de7c9b0

> 3. Processing of out-of-order TCP packets, and a larger window size.
> These are the main thing which kill gPXE WAN performance as far as I
> can tell.  If that means adding an interface to the NBP to allocate
> additional buffer space, then that can be done.

In progress.  One of our GSoC students is working on TCP performance
improvements and has some promising results:

http://git.etherboot.org/?p=people/cooldavid/gpxe.git;a=commit;h=d79ea5290a47efdc31de0661d2b68879744013cb

He will continue working on these improvements during the second half of
GSoC 2010, and we hope to be able to include them in the near term.

> 4. A spec for the gPXE configuration file variables.  I am hoping to
> introduce similar macros in Syslinux 4, and it would be rather
> pathetic if they weren't compatible.

This is something we really need to talk about.  It speaks the question
below, since we need to consider the basic purpose and scope of gPXE.

Scripting language and macros is a topic that needs and deserves its own
thread, so let's get one going.  I think a number of people have
thoughts and ideas on this, and maybe we have critical mass for deciding
on a direction that let us get code into mainline.

> 5. Focus on the low level, not high-level features.  Being a good
> PXE/UNDI stack is by far the most important for Syslinux.

I tend to feel this way, but deciding on the boundaries between high and 
low-level features is going to require some thought and discussion.

I am ready to have this discussion, because I think that by having it we 
will be able to become better firmware.

What particular features do you think deserve emphasis and deemphasis?

gPXE is capable of a lot, but there are certainly things that could be 
moved to a second-stage bootloader.  Let's talk about this.

> 5a. Syslinux (not 4) probably will be using lwIP anyway, and would
> use gPXE for initial bootstrap and as an UNDI provider.  The reason
> is that the NBP simply can achieve much higher performance since it
> has full control of memory -- and tests bear this out.
>	-hpa

Is this still true (the lwIP part)?  I know that increasing window size 
has improved performance, but I am not sure whether you still are 
planning to use lwIP at this point.

My hope is that we the improvements mentioned above in TCP performance 
gPXE may yet provide acceptable performance for your purposes.

We try to work as well as we can with as many software and hardware 
components as we can, and pxelinux compatibility is certainly one of the 
most important software components we interoperate with.

So, Peter, what's your view of things 6 months removed from when you 
wrote your message?

/ Marty /

P.S. Anyone else with thoughts on this is welcome to join in this 
discussion.  I am looking for good ideas that will propel us forward, 
and we have a lot of smart and passionate people doing good work, so 
please speak up if you have an opinion!



More information about the gPXE-devel mailing list