Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2010:cooldavid:project_plan:start [2010/05/01 06:06] cooldavid |
soc:2010:cooldavid:project_plan:start [2010/07/20 00:03] (current) cooldavid |
||
|---|---|---|---|
| Line 4: | Line 4: | ||
| ==== Summary ==== | ==== Summary ==== | ||
| - | In order to have better performance on 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. | + | 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 ==== | ==== 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 ==== | ==== 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: Update jme driver, Trace memory related codes]] | ||
| + | * [[soc:2010:cooldavid:journal:week3|Week 3: Trace memory related codes, misc things]] | ||
| + | * Week 4-7: Studying for PhD qualify exam. | ||
| + | * [[soc:2010:cooldavid:journal:week8|Week 8]]: | ||
| + | * Several TCP fixes | ||
| + | * [[soc:2010:cooldavid:journal:week9|Week 9]]: | ||
| + | * TCP cleanup | ||
| + | * Trace gPXE boot initialize steps about memory environment setup. | ||
| + | * [[soc:2010:cooldavid:journal:week10|Week 10]]: | ||
| + | * Cleanup TCP receive queue/SACK/Window scale patches | ||
| + | * Submit it on the list, having some test and feedback. | ||
| + | * [[soc:2010:cooldavid:journal:week11|Week 11]]: | ||
| + | * Testing TCP performance with different window size, network environment. | ||
| + | * Discuss the testing results and find a reasonable size. | ||
| + | * [[soc:2010:cooldavid:journal:week12|Week 12]]: | ||
| + | * Possible more TCP cleanup, tuning. | ||
| + | * gPXE scheduling and program flow documentation. | ||
| + | |||
| + | === After GSoC period === | ||
| + | * Help on porting tg3 driver. | ||
| + | |||
| + | ==== 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. | ||
| + | |||
| + | ==== Postponed stuff from original plan ==== | ||
| + | * tg3 driver for gPXE. | ||
