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. :)