98 lines
2.9 KiB
Plaintext
98 lines
2.9 KiB
Plaintext
|
Just some general thoughts that have occurred to me as I've started
|
||
|
|
looking at stuff related to designing a network stack...
|
||
|
|
|
||
|
|
These are in no particular order.
|
||
|
|
|
||
|
|
General Jottings
|
||
|
|
----------------
|
||
|
|
|
||
|
|
- zero-copy is a laudible aim, but in reality single copy is probably
|
||
|
|
as good as we're going to get to. Basically this means that we copy data
|
||
|
|
into the stack at some point.
|
||
|
|
- we should use a version of the mbuff's that the BSD stack uses with changes
|
||
|
|
so we use them more efficiently for our stack.
|
||
|
|
- probably need an rx and tx queue for frames.
|
||
|
|
- we should reallt be dealing with frames as soon as we can in the stack,
|
||
|
|
though we don't want to fragment earlier than we need to - what a quandry!
|
||
|
|
- it should be possible to stack/reorder modules as needed. This would be cool
|
||
|
|
if we could deal with input from other sources, e.g. data from a USB port
|
||
|
|
to be fed into a ppp stack, onto an atm/ethernet frame module and upwards.
|
||
|
|
|
||
|
|
|
||
|
|
Userland vs Kernel Land
|
||
|
|
-----------------------
|
||
|
|
|
||
|
|
This has been decided as follows...
|
||
|
|
- initial stack will be userland
|
||
|
|
- stack should be modular enough that it could be moved into kernel with
|
||
|
|
little or no real work.
|
||
|
|
|
||
|
|
|
||
|
|
Initial Protocols
|
||
|
|
-----------------
|
||
|
|
|
||
|
|
- ethernet/802.x encapsulation (rx only for 802.x)
|
||
|
|
- slip (?)
|
||
|
|
- ppp (?)
|
||
|
|
- arp
|
||
|
|
- ipv4
|
||
|
|
- icmp (v4)
|
||
|
|
- udp
|
||
|
|
- tcp
|
||
|
|
|
||
|
|
Extra's
|
||
|
|
-------
|
||
|
|
|
||
|
|
- appletalk ?
|
||
|
|
- ipv6
|
||
|
|
- icmpv6
|
||
|
|
- ipv6 discovery (arp for v6)
|
||
|
|
- atm encapsulation module?
|
||
|
|
- usb interface (net stack to usb??)
|
||
|
|
|
||
|
|
Stack Map
|
||
|
|
=========
|
||
|
|
|
||
|
|
So, how does this all fit together???
|
||
|
|
|
||
|
|
[david: My ascii art is terrible, so hope this works out :)]
|
||
|
|
|
||
|
|
=================
|
||
|
|
= User apps = USERLAND
|
||
|
|
=================
|
||
|
|
| | |
|
||
|
|
| | |
|
||
|
|
========= ========= =========
|
||
|
|
= UDP = = ICMP* = = TCP =
|
||
|
|
========= ========= =========
|
||
|
|
\ | /
|
||
|
|
\ | /
|
||
|
|
===============
|
||
|
|
MBUF = IP (v4/v6) =
|
||
|
|
===============
|
||
|
|
|
|
||
|
|
-----------------------------
|
||
|
|
| |
|
||
|
|
=============== | =======
|
||
|
|
BUFFER = Eth/802.x =----|---= ARP =
|
||
|
|
=============== | =======
|
||
|
|
| |
|
||
|
|
----------------------------|-----
|
||
|
|
| |
|
||
|
|
=========== |
|
||
|
|
= NIC IF = | KERNEL
|
||
|
|
===========
|
||
|
|
|
||
|
|
* ICMP is used as a placeholder for both ICMPv4 and ICMPv6, which are very
|
||
|
|
different from each other in scope and usage.
|
||
|
|
|
||
|
|
Basically every module only needs to be able to call the module that deal with the
|
||
|
|
input/output of the protocol it find encapsulated, i.e. if IP finds a TCP packet
|
||
|
|
it simply needs to be able to call tcp_input and pass the mbuf along. There is a
|
||
|
|
requirement that each call to xxx_input gives the length of the header as they're
|
||
|
|
variable in most protocols.
|
||
|
|
|
||
|
|
This just starts to scratch the surface, but I hope gives more of an idea
|
||
|
|
of what's been bouncing around in my head. :)
|
||
|
|
|