Network Stack Code Re-write (Possible motivations...?)

[Lowell Gilbert]

Wojciech Puchar <wojtek at wojtek.tensor.gdynia.pl> writes:

>> I very much doubt that marketing issues were a significant issue.
>> Off-the-shelf OS networking has always fallen short of supporting
>
> it wasn't made for that.

It can be.  I've written portable IP stacks intended for exactly this
purpose.  The routing tables are generally set up in userspace
regardless, so it's not a big problem to send the same data to multiple
stacks where each stack is supporting a different application.

>> As someone else already mentioned in this thread, supporting hardware
>> offload for forwarding is a major issue.  Core routers (or even
>> provider-edge routers) depend on most of the packet forwarding being
>> done in proprietary hardware. Operating system IP stacks don't support
>> this very well; all of the routers I've worked on used the kernel IP
>> stack only for packets going to and from the kernel itself, and used a
>> different stack for what I call "transit" packets -- those that are
>> only being forwarded by the local system.
>
> as higher speed routers are "hardware" - why OS has to do ANY work on
> routing?
>
> it's just there to prepare routing tables in format required for
> routing ASIC's and put them there!

Mostly, yes.  But the system still has to be network manageable.  That
requires that it send and receive packets.  Doing so requires using the
same routing information that the forwarding engines are using to
forward packets in the same address space.  The kernel *does* still need
to know routes to any of its destinations.

Another possible implementation is, as you say, to have the kernel send
everything out the same way and not know anything about the forwarding
tables.  This does, as the original poster said, imply that you're
throwing out the capabilities of a stack that you built into your system
from the ground up.

-- 
Lowell Gilbert, embedded/networking software engineer, Boston area
		http://be-well.ilk.org/~lowell/