This is an old revision of the document!
==== Week 2 [ 31 May - 6 Jun 2010 ]: Discuss TCP and memory changes, update jme driver ==== ==== jme driver ==== * From Joshua Oreman * jme_check_link(struct net_device *netdev, int testonly)\\ * In this function, I believe the code and string data used in constructing linkmsg will make it into even non-debug versions of the executable. If that's true it would be better if you could perform all the manipulations in the final DBG() line, using the ?: operator and such. It's possible the compiler is clever enough to know what strcat() does and see that linkmsg[] is not used in non-debug, though, so this may be moot. * From Michael Brown * if (memcmp(addr, netdev->hw_addr, ETH_ALEN)) * No need for this compare; just always write the MAC address. (This code will fail if you set the MAC to a non-default value, then try to set it back.) * Code cleanups * gPXE dose not use any DMA address that is above 4G <code C> #if __x86_64__ rxdesc->desc1.flags = RXFLAG_64BIT; #endif </code> * Use struct ethhdr and eth_ntoa(). * Drivers should generally not try to parse the packets they transmit and receive. * This code will break if/when software VLAN support is added. <code C> DBG2("Received packet: " "from %02x:%02x:%02x:%02x:%02x:%02x " "to %02x:%02x:%02x:%02x:%02x:%02x " "type %04x\n", *(uint8_t *)(rxbi->data + 6), *(uint8_t *)(rxbi->data + 7), *(uint8_t *)(rxbi->data + 8), *(uint8_t *)(rxbi->data + 9), *(uint8_t *)(rxbi->data + 10), *(uint8_t *)(rxbi->data + 11), *(uint8_t *)(rxbi->data + 0), *(uint8_t *)(rxbi->data + 1), *(uint8_t *)(rxbi->data + 2), *(uint8_t *)(rxbi->data + 3), *(uint8_t *)(rxbi->data + 4), *(uint8_t *)(rxbi->data + 5), be16_to_cpu(*(uint16_t *)(rxbi->data + 12))); </code> * %p should be used for printing out pointer values. <code C> DBG2("TX buffer address: %08lx(%08lx+%x)\n", (unsigned long)iob->data, mapping, len); </code> * This will behave poorly when memory runs out. Better is to have a refill routine that runs after the poll(), and always attempts to refill up to a specified level. <code C> rxdesc += idx; if (jme_make_new_rx_buf(rxring->bufinf + idx)) { DBG("Dropped packet due to memory allocation error.\n"); netdev_rx_err(netdev, NULL, -ENOMEM); } else { </code> ==== Trace memory related codes ==== * Current heap size is fixed at 128K. * Trying to figure out a way to obtain more memory, and report it to OS. * See if it is possiable to know how much heap size we can use out of code and stack. === Schedule for memory and TCP modifications === - Trace how the gPXE boot, relocate, and fill segment informations. - Try to understand how Michael Brown removes the even magabyte limit. - Start a discussion on the list about how to reasonably extend gPXE's usable memory. - Patch gPXE to support large(Several MB perhaps) heap memory. - Design/discuss a TCP receive window advertisement algorithm. - Patch gPXE with ''**TCP receive queue**'', ''**SACK Support**'', and ''**Window scale**''. - Do some benchmark against different window size, and different network environment. - Post the result and discuss it on the gpxe mailling-list. === Some notes after trace === * [[soc:2010:cooldavid:notes:gpxememlayout|gPXE memory layout]] * Good articals for understanding Gate-A20 - [[http://en.wikipedia.org/wiki/A20_line|WIKIPEDIA - A20 line]] - [[http://www.win.tue.nl/~aeb/linux/kbd/A20.html|A20 - a pain from the past]] === Expand heap === The gPXE's code can be executed on both real-mode and protected-mode because of the GDT's base address was filled with the starting point of the code. Which makes all the function, global variable's pointer valid between the transition. Also, the limit of GDT entry was set to 4G, so there is no need to concern if we are going to across the segment limit. Since the heap is not used by real-mode code, and is used at late stages of gPXE. I think it might be possible to put the heap out side of the .bss section, and put it at the very end of the image. After we put the heap at the very end of the image, we can make sure that no data might be needed for real-mode codes would put beyond 1MB limit. Currently I left 128KB for stack to grow, and put the heap right behind it. The C code which runs in protected-mode would work fine, since it's already using 32 bit addressing, and the segment limit is way larger than image size. For the real-mode code, as long as the heap is not used. All the data needed should be within 1MB limit. [[http://git.etherboot.org/?p=people/cooldavid/gpxe.git;a=commitdiff;h=09be316b2b1538860037233b41a43dfb3bb1f3d8|Commit-diff]] === Original heap location === [[Original heap location|{{http://bbs.cooldavid.org/pic/origheap.png}}]] === Modified heap location === [[Modified heap location|{{http://bbs.cooldavid.org/pic/hugeheap.png}}]]
