Question

I was taking a look at using PF_RING for sending and receiving in my application.

If I plan to use PF_RING for maintaining a TCP connection, it looks like I’ll need to manually “forge” the IP and TCP messages myself, as pfring_send sends raw packets. Does this mean I’ll have to manually reimplement TCP on top of PF_RING?

I understand there is a clear advantage for receiving using PF_RING, has anyone tried sending data with PF_RING? Is there a clear advantage over normal send calls?

note: I am not using DNA (Direct NIC Access), I am just using the kernel partial bypass with NIC aware drivers.

Answer 1

To answer your first question, yes, you will have to manually build the TCP/IP messages from the ground up, MAC address and all. For an example take a look at pfsend.c from ntop.org.

ntop.org has also made a PF_RING user guide available that contains explanations.

As for sending data using PF_RING, it is absolutely possible, the idea is to bypass any and all notion of what is actually data on the wire and send as fast as possible, see wire speed traffic generation from ntop.org. The only advantage it has over normal sending calls using the kernel for TCP/IP is that you can send data 1. faster and 2. completely unformatted onto the wire. 2 can be handy for example when you want to play back a previously captured packet/multiple packets onto the network.

---

Unless you have a specific use case that requires you to get access to the raw underlying data without kernel intervention there is absolutely no good reason to use PF_RING in any way. Your best bet would be to use the standard socket()‘s that are available, in most cases the performance you can achieve with that is more than adequate.

What specific use case did you have in mind?