Sorry if this has already been sent to the list.
http://newsroom.cisco.com/dlls/2008/prod_101408e.html
The new uIPv6 stack requires only 0.5 KB of SRAM for data structures, a minimum of 1.3 KB of SRAM for buffering, and 11 KB of flash for the code.
/tia damjan
-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Stanislav Sinyagin Sent: Montag, 2. März 2009 23:15 To: swinog@swinog.ch Subject: Re: [swinog] IPV6 Go (lazy providers)
hi Tonnerre,
From: Tonnerre Lombard tonnerre@bsdprojects.net
What you can fit into 2MB flash is Linux kernel 2.4.x, plus some very limited number of libraries, daemons and utilities. Also, even the newest 2.6.x kernel is permanently popping up with ipv6 improvements and bugfixes. It is physically impossible to run a 2.6.x Linux system from 2MB flash. You can, however, run it from 4MB, and there's even some room for ipv6. The dd-wrt software for Linksys routers seems to support it, but I didn't test it.
A slimmed down NetBSD kernel can fit into 2MB including IPv6 support. (You have to put some work into it though.)
unfortunately, NetBSD is way behind Linux in regards to new hardware support, especially for those consumer-grade devices. Most of the new reference boards come with quite poorly designed Linux BSP, and I haven't heard of any BSD support from the embedded hardware vendors.
Besides, as I told already, this linux/bsd hacking is for geek enthusiasts. Consumer electronics vendors will just push new hardware to the market.
Some of those devices are hardware-fixed to little endian architecture, even if the CPU allows running either BE or LE (bit noth both at the same time). In LE architectures, you have to swap bytes in every packet header in order to get the IP address or TCP port number. This slows down ipv6 processing significantly, as there are many more bytes to swap.
That should only apply if you use arithmetic comparison functions. For pure subnet calculations and matching, you can work on the unswapped data (if you always compare in network byte order, which isn't hard). There goes your bottleneck.
I looked into the ipv6 linux kernel sources, and found quite a lot of hton/ntoh conversions. Also, for example, subnet mask matching is way more complex in foreign endianness :)
(Also, what kind of argument is this? IPv4 also needs to be byteswapped.)
ipv6 has many more bytes to swap in the packet header, that's the only reason :)
_______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog