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-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch] On Behalf Of Stanislav Sinyagin Sent: Montag, 2. März 2009 23:15 To: swi...@swinog.ch Subject: Re: [swinog] IPV6 Go (lazy providers) hi Tonnerre, > From: Tonnerre Lombard <tonne...@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 _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
