Receiving recommendations for commercial TCP/IP stack implementation based on FreeBSD or NetBSD. Requirements are similar to a typical desktop PC running a browser, email and streaming voice/video. Which is to say a rich network functionality for a end-host type of device with mature implementation and reasonable performance.
BSD derived network stacks are deployed in wide variety of situations for years and hence have mature implementation.
It's supposed to run on a proprietary RTOS.
Most vendors I found don't advertise if their stack is based on BSD. Any recommendations?
-- Vineet
It's not commercial, but you could take a look at OSkit. It uses FreeBSD's networking stack. It might be easier to take the stack out of OSkit than from FreeBSD
http://www.cs.utah.edu/flux/oskit/
Related
I'm trying to learn network protocol stack(ie. Transport, IP, datalink layer library code implementation) along with linux. I'm confused where to start.
First question is whether these codes come as in-built features of linux kernel/above library layers.
If so why I can see 3rd party protocol stack in some applications (by blunk micro system - developer of protocol stack)
If Linux doesn't have it as core feature, is linux give only placeholders for network part(like just Macros to enable the 3rd party stack ). But an article says it has Net4 networking codebase.
If linux has in-built network features what are the linux modules I need to go through or where to start? Not only in the network perspective, if i'm guided to explore in linux in all aspects (process, memory, drivers) in the "code level", it would be helpful please.
Note: I'm greedy to write my own OS and protocol stack hence trying to understand an existing system.
Thanks in advance!
First question is whether these codes come as in-built features of linux kernel/above library layers.
Linux kernel has network stack up to including layer 4, i.e., TCP and UDP (well, kernel + a set of utilities needed to configure it). I think DNS is in kernel too, but I am not so sure. TLS used to be implemended as a library (OpenSSL and GnuTLS are I think the most common ones), but there seems to be kernel part too now (link.
Note, that some of the TCP functionality is offloaded to the network card (hardware). At high speeds (1Gb+) you won't get full performance without these features.
I am not familiar with all VoIP related protocols, but I think they are libraries, not kernel.
If so why I can see 3rd party protocol stack in some applications (by blunk micro system - developer of protocol stack)
I believe the reason is performance. If you implement a custom stack with a subset of features, it might work better for your applications. Also there are advanced features and protocols that might not be available in the kernel itself.
If Linux doesn't have it as core feature, is linux give only placeholders for network part(like just Macros to enable the 3rd party stack ). But an article says it has Net4 networking codebase.
there is a very large codebase
If linux has in-built network features what are the linux modules I need to go through or where to start? Not only in the network perspective, if i'm guided to explore in linux in all aspects (process, memory, drivers) in the "code level", it would be helpful please.
hmmm, this is a very good question, and I don't think there is an easy answer. In my experience reading the code is the only way to figure this out. However some people tried to fish LWN.net for information.
you could probably start somewhere here: include/net/
First question is whether these codes come as in-built features of linux kernel/above library layers.
If linux has in-built network features what are the linux modules I need to go through or where to start?
You can think of a protocol stack as of a library. Linux kernel has one which runs inside the kernel address space and uses kernel APIs unavailable in user-space: https://github.com/torvalds/linux/tree/master/net/ipv4
There are multiple in-depth books about Linux kernel networking. Reading one is required for good understanding.
If so why I can see 3rd party protocol stack in some applications (by blunk micro system - developer of protocol stack)
Zero-copy, low-latency and streaming (processing an Ethernet packet in CPU-L1-cache-line-sized chunks while it hasn't been read off the wire in full) networking have been problematic with Linux kernel network stack. For these reasons makers of networking hardware offered their own user-space network stacks, aka kernel bypass.
Linux kernel network stack is getting better these days with MSG_ZEROCOPY and io_uring.
I'm trying to find out if there is any native TCP/IP stack implemetation provided in DPDK or any popular open-source project to achieve it. Any help will be grateful.
Update:
My platform is Ubuntu 16.04 x64, Intel 82599es NIC with DPDK 20.08. What I'm trying to accomplish is to rebuild TCP connections out of the packets I receive on the NIC port for later use. I thought tools like ANS, mTCP and fstack may do the track but they are third party and some of them are not fully open-sourced, so I'm looking for a native one or one that is popular for developers. I don't know what should I call this kind of requirement, sorry for troubles causing because of the question, I'll change it after I know the related concept better.
There are no native TCP-IP stack implementation in DPDK version till date DPDK version 20.11 LTS. Going further in my humble opinion DPDK would not be implementing native TCP-IP stack. Hence current options are
Since the requirement is to rebuild TCP connection state information, my recommendation is to
create RTE_FLOW_ACTION_MIRROR to create the packet copy at HW NIC level for all interested TCP connection using a combination of IP-TCP address-ports.
If there is no HW option, either using ref_cnt_update or copying the user packet payload create a copy of the packet.
With help RTE_RINGS or RTE_FB_ARRAY organize the packets from client and server based on symmetric RSS (if available) or based on custom HASH to appropriate containers.
For you packet processing recommendation is either use FSTACK or mTCP or BSD TCP-ip from scratch
there are multiple references on the Internet which gives hints to get started too. Please refer
mTCP slide 14
fstack slide deck
"Commercial software routers from companies such as Vyatta can typically only attain transfer data at speeds of up to three gigabits per second. That isn’t fast enough to take advantage of the full speed of a typical network card, which operates at 10 gigabits per second." [1]
How is the speed of the network interface card relevant in this scenario? Aren't software routers connecting multiple Virtual Machines running on the same physical host? [2] Unless a PC has multiple network interface cards, it is unlikely that it functions as a packet switch between different physical hosts.
My interpretation suggests that there seem to exist two different kinds of software routing: (1) Embedding a real time operating system on an actual router. (2) Writing application layer code on a PC that can handle packets being transmitted between different virtual machines running on that very PC. Is this correct?
It depends on what your router is doing. If it's literally just looking at a static route table and forwarding packets out another interface, there isn't much hit in performance.
It's when you get into things like NAT, Crypto, QoS, SPI... that you will see performance degradation. Hardware vendors are usually using custom silicon to process the more advanced features, this allows for higher throughput packet forwarding.
Now that merchant silicon is fast enough and the open source applications are getting better, the performance gap is closing.
It really depends on your use case as far as what you want to use. I've gone with both and not seen performance hits, but the software versions weren't handling high throughput workloads.
Performance of the link from the virtual network to the physical eventually becomes important at any reasonable scale. You're right that, within the same physical host, things can be pretty quick, but that requires that one can get everything needed in one box.
While merchant silicon has come a long way in improving the performance of networking equipment, greater gains are taking place getting CPU's to handle networking tasks better. Both AMD and Intel have improved their architectures to the point where 10 Gbps forwarding is a reality. Intel has developed a specialized library (DPDK Wiki Page) that takes care of a lot of low-level networking functions at high performance.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anyone have especially good (or bad) experiences with any of the following embedded TCP / IP stacks?
uIP
lwIP
Bentham's TCP/IP Lean implementation
The TCP/IP stack from this book
My needs are for a solid, easy-to-port stack. Code size isn't terribly important, performance is relatively important, but ease of use & porting is very important.
The system will probably use an RTOS, that hasn't been decided, but in my experience most stacks can be used with or without an RTOS. Most likely the platform will be an ARM variant (ARM7 or CM3 in all likelihood).
Not too concerned about bolting the stack to the Ethernet driver, so that isn't a big priority in the selection.
I'm not terribly interested in extracting a stack out of an OS, such as Linux, RTEMS, etc.
I'm also not interested in commercial offerings such as Interniche, Micrium, etc...
The stack doesn't need all sorts of bells & whistles, doesn't need IPv6, and I don't need any stuff on top of it (web servers, FTP servers, etc..) In fact it's possible that I'll only use UDP, although I can envision a couple scenarios where TCP would be preferable.
Experiences with other stacks I've missed are of course also very much of interest.
Thanks for your time & input.
I've used both uIP and lwIP extensively.
uIP
Great if youre only wanting something basic like a bootloader
Small footprint.
Uses polling so we've never got over 3kbit with it :-(
No DHCP 'out of the box'
Poor UDP support
lwIP
Fully interrupt driven so much faster (~ x10)
Includes DHCP with failover AutoIP
UDP with multicast
Plus more
EDIT:
And we've never used either with an RTOS as there has never been a need.
+1 for lwIP.
We used this successfully on a project a few years back and found it to be generally very reliable. We found and fixed a few issues (generally corner cases within the TCP code) which we submitted back to the project, and even though the project has moved on quite a bit since then we didn't generally find it lacking in any features.
As you suspect it will work with or without an RTOS. It took about a week to get running on our system with an RTOS, which included changes we had to make to support an unusual DSP compiler. As you're probably using GCC on ARM you can avoid any of that effort.
It does contain many more features than you require, but if your requirements change a few years down the line then you'll be better off having started out with a more substantial stack.
lwIP
I worked on a project with a 3G modem where we needed a UDP/IP stack (no TCP) on top of PPP. We narrowed down to uIP and lwIP. We picked lwIP in the end because it had PPP already (uIP doesn't), and we had enough RAM to spare.
Our particular project didn't use an RTOS, and lwIP was fine to use without an RTOS.
I wasn't directly involved in porting the lwIP code, although I worked on the modem driver to interface with it. My impression was that the porting took a couple of weeks to get everything going smoothly, for our engineer who had previous TCP/IP experience. The lwIP code has been hacked by many people, and consequently has some rough edges (e.g. someone threw in a lone malloc() somewhere) but it worked for us after a little tweaking. We tested it with an independent validation suite.
In summary, it was "suitably functional" for our UDP/IP and PPP needs (but I can't comment on its TCP capabilities).
+1 for lwIP.
It is included in the Luminary Micros (now TI) Serial to Ethernet reference design with some added capabilities (some sort of "server side scripting" and cgi) working on bare metal (without RTOS).
It is rock solid and very performant with only 32KB or RAM.
Regards
PFM
I am pleased with lwip on the Stellaris Cortex-M3.
StellarisWare for the LM3S6965 eval board includes the enet_lwip demo. This is a small web server running over lwip which is running over bare metal -- no FreeRTOS in this case. The system is driven by the timer and Ethernet interrupts. It was pretty easy to rip out the web server and drop in my app. I did not have to become an lwip expert to get this running the first time.
Later I realized that my app was intrinsically up-call driven. At first, it had a sockets-to-upcall gasket. I replaced that layer with a much simpler one that translates lwip native upcalls to the app's upcalls, and optioned out lwip's socket API. This saved more flash and RAM space, and made the whole thing faster and simpler. With a little tweaking I got it running on the S2E board using 52K flash and 30K RAM.
You can try the open-source FNET TCP/IP stack.
I've used the Microchip TCP/IP stack. I've been very happy with it. It was very easy to implement, lots of demo code/tutorials available, and has support for a lot of protocols HTTP, tFTP, SMTP, SNTP, etc. A point that doesn't match your requirements however is that it is not easily portable to another architecture. In fact I think the license for the stack explicitly forbids this because Microchip wants you to run the stack only using their hardware the PIC18, PIC24, and PIC32. There is however an external Ethernet controller they sell that they will allow you to use certain portions of this stack with their ENC28J60.
I have used Interniche on FreeRTOS.
It's a full-fledged stack and supports quite a few features.
Since you are looking for a non-commercial version, my vote is on lwIP.
In most modern operating systems like Linux and Windows, is network IO typically accomplished using DMA? This is concerning generic Ethernet controllers; I'm not asking about things that require special drivers (such as many wireless cards, at least in Linux). I imagine the answer is "yes," but I'm interested in any sources (esp. for the Linux kernel), as well as resources providing more general information. Thanks.
I don't know that there really is such a thing as a generic network interface controller, but the nearest thing I know of -- the NE2000 interface specification, implemented by a large number of cheap controllers -- appears to have at least some limited DMA support, and more sophisticated controllers are likely to include more sophisticated features.
The question should be a bit different:
Is typical network adapter have dma
controller on board ?
After finding answer on this question ( i guess in 99.9% it will be yes), you should ask about specific driver for each card. I assume that any decent driver will fully utilize hardware capabilities (i.e DMA support in our case), but question about OS is not relevant, since no OS can force the driver to implement DMA support. A high level OS like Windows and Linux provide a primitives to easier implementation of DMA, but implementing is responsibility of the driver.