✎ soc:2010:cooldavid:project_plan:start

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Guo-Fu Tseng: Implement and Port Ethernet Drivers for gPXE ======

===== Project Plan =====

==== Summary ====
In order to obtain better performance from JMicron Ethernet Card. Instead of using the UNDI driver, I would implement a better performance native driver for gPXE. The tg3 driver of gPXE project still using old etherboot API, I would buy a Broadcom NIC and try to port it into new gPXE API.

Implement TCP receive queue to handle out-of-order packets, and SACK, window scaleing support. To have better performance on high latency network(WAN), or unstable networks(Wireless).

==== Outline ====
Most of work for porting driver is to understand what original
driver does, and remove all un-need code from the Linux driver.
The JMicron driver should be much more easy for me since I've
already written the Linux driver. But the broadcom tg3 driver
might take me more time since I have to guess lots of things due
to lack of chip spec.

Current gPXE limited the TCP window size at 4KB. Which makes sence
when the TCP stack dose not handle out-of-order packets, in order
to prevent large amount of useless packets on slow and unstable
network(Such as wireless). That is
  * The packet is dropped often.
  * The bandwidth is narrow.
  * The receiver
    * Dose not queue non-contigious packets
    * Advertived a large window.
  * Any packet dropped:
    * Sender have no idea about it.
    * Send all remaining data to receiver until window is filled.
    * Consume more bandwith in narrow bandwith, but useless.
    * Makes the network worse.

But with receive queue and SACK implement, ideally the sender don't
have to send any data that was received by the receiver. It would be
much more better for above senariol with larger window size.

For [[http://en.wikipedia.org/wiki/Bandwidth-delay_product|long fat network]]
the window size is important also. In order to have large enough window size,
we need [[http://tools.ietf.org/html/rfc1323#page-8|window scale option]] to
breake the 64K window size limit.

But the original gPXE's heap was fixed at 128K due to A20 limit, and
have to perserve the space for codes. We recently found that the
all-driver image has almost reached the 1MB limit. This should be the
issue we solve first.

After solving the heap memory limit, I'll have some benchmark to see
what's the reasonable MAX TCP WINDOW SIZE, and advertice a reasonale
window size.

==== Milestones and Timeline ====
=== JMicron Ethernet Driver ===
  * [[soc:2010:cooldavid:journal:weekb4|Week -4: Debug hardware problem]]
  * [[soc:2010:cooldavid:journal:weekb3|Week -3: Trace gPXE code base]]
  * [[soc:2010:cooldavid:journal:weekb2|Week -2: Implement JMicron driver]]
  * [[soc:2010:cooldavid:journal:weekb1|Week -1: Modify JMicron driver, RX offloading]]

=== Tuning TCP stack ===
  * [[soc:2010:cooldavid:journal:week0|Week 0: TCP performance test and tunning]]
  * [[soc:2010:cooldavid:journal:week1|Week 1: Update wiki, TCP tunning]]
  * [[soc:2010:cooldavid:journal:week2|Week 2: Discussing TCP and memory changes]]
  * Week 3-6:
    * Have a solution for bigger heap size.
    * Fine tune window size, heap size.
    * Clean-up TCP receivw queue/SACK/Window scale patches.
    * Submit it on gPXE-devel, and discuss it.

=== Broadcom tg3 driver ===
  * Week 7:\\
    * Trace tg3 driver of both Linux and gPXE.
  * Week 8-10:\\
    * Port latest tg3 driver from Linux to gPXE.
  * Week 11-12:\\
    * Testing and Debuging.

==== Extra stuff from original plan ====
  * Ethernet RX checksum offloading support
  * TCP out-of-order receive queue
  * TCP Selective acknowledgement [RFC 2018][RFC 1323]
  * TCP Window scale [RFC 1323]
  * TCP PAWS(Protect Against Wrapped Sequence Nunbers) [RFC 1323]
  * Possible tunning TCP/HTTP xfer interface.
Trace: • journal • notes • week2 • ubuntubko • week10 • journal • week4 • journal • week12 • journal
Navigation

Search

Toolbox

QR Code
