Results 1 to 2 of 2
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Apr 2012
Layer 2 network protocols development
I'm new to Linux kernel programming so I'll ask you for advice: I'm interested in networking, especially the development of layer 2 tunneling protocols such as FCoE, IBoE, and many other protocols over Ethernet.
Could you recommend me books or some kind of guides from the net. I am wondering whether I need strong programming skills to do this, or just good knowledge of the kernel networking libraries and the structure of the protocols is enough.
Thank you very much. I am waiting for your answers.
I can tell you the following:
- When working with protocols, you need to deal with two parts: the control plane and the data plane (aka the forwarder). The techniques used for one may not necessarily work well for the other.
- It's probably best to write your control plane software as a user-space application. It can configure the forwarder using ioctl or netlink sockets. It can receive any relevant packets either using AF_PACKET sockets or with a protocol-specific address family installed by a kernel driver.
- For the forwarder, you might be able to leverage existing L2 forwarding kernel code, but it is more likely that you'll have to write one. It's not hard to write a forwarder, but it is very hard to write one with high performance (high throughput, low latency, etc.) You can develop one that runs in user space (using AF_PACKET sockets), but for good performance, you'll need to write it as a kernel driver.
- Even with a kernel driver, however, no software-based forwarder is going to be able to work as well as a hardware-based forwarding chip (like a network processor.) You can probably get line-rate forwarding at 100M for a small number of ports with a software forwarder, but that's about it. If you need faster speeds or a lot of ports, you'll need to consider a hardware solution.
- All the major manufacturers of network processors (Broadcom, Intel, IBM, etc.) provide SDKs for programming the chips, so you don't need to directly manipulate the chips, but even with an SDK, there can be a steep learning curve. Such learning is probably beyond the scope of this forum. (And I can't help here, because I've never written code for a chipset SDK.)