Initial PF_RING support (receive only)

[cardigliano]

This patch adds PF_RING support for RX only. All the code is under #ifdef HAVE_PF_RING.

[tklauser]

Thanks for your PR and your interest in contributing to netsniff-ng!

While I generally think netsniff-ng would profit from adding support for PF_RING, I currently see a few issues with the way this is achieved in this PR:

• It requires PF_RING libraries/modules(?) to be installed manually by the used in their $HOME. Preferably this should not be necessary and it would be great to solely rely on distribution packages. Also it seems an out-of-mainline Linux kernel module is required to run PF_RING. Are there any plans to upstream this? As for netsniff-ng, we would really prefer to be able to run on an on-modified vanilla kernel.
• The use of PF_RING is protected via a lot of #ifdef which we try to avoid in the netsniff-ng code base whenever possible. Would it be possible to factor out the PF_RING specific bits into its own file/module and then call out to them? Maybe this requires to rework some of the existing infrastructure, but it would still be the preferred way of handling this. E.g. I could imagine something like a pluggable capture API of which the existing PF_PACKET one and the newly added PF_RING could be implementation.
• It would also be nice to have a bit more information about PF_RING in the commit message, i.e. what problems it solves, what advantages/disadvantages it has compared to other capturing methods, etc.. Also some benchmark data would be nice, comparing it to PF_PACKET v2/v3.

/cc @borkmann @vkochan what do you think?

[cardigliano]

It requires PF_RING libraries/modules(?) to be installed manually by the used in their $HOME. Preferably this should not be necessary and it would be great to solely rely on distribution packages.

I agree it should rely on installed libraries/headers. This is something I was planning to do asap.

Also it seems an out-of-mainline Linux kernel module is required to run PF_RING. Are there any plans to upstream this? As for netsniff-ng, we would really prefer to be able to run on an on-modified vanilla kernel.

Please note there is no need to modify the kernel in order to use PF_RING, all you need to do is to load a kernel module.

The use of PF_RING is protected via a lot of #ifdef which we try to avoid in the netsniff-ng code base whenever possible. Would it be possible to factor out the PF_RING specific bits into its own file/module and then call out to them? Maybe this requires to rework some of the existing infrastructure, but it would still be the preferred way of handling this. E.g. I could imagine something like a pluggable capture API of which the existing PF_PACKET one and the newly added PF_RING could be implementation.

The capture API is something I wanted to suggest you and this project definitely needs. Unfortunately the current code is really tied to PF_PACKET and I had to change the code in many places.

[tklauser]

I agree it should rely on installed libraries/headers. This is something I was planning to do asap.

Great, looking forward to that!

Please note there is no need to modify the kernel in order to use PF_RING, all you need to do is to load a kernel module.

I see. Are you planning to submit the module/driver for mainline kernel inclusion? Are you also packaging it for distribution packages as long as it is not part of the mainline kernel?

The capture API is something I wanted to suggest you and this project definitely needs. Unfortunately the current code is really tied to PF_PACKET and I had to change the code in many places.

Great! Feel free to propose whatever works for you (and of course doesn't restrict the current PF_PACKET based implementation 😉).

[vkochan]

This is not related to this patch, but I think it would be good if the fast& slow path mechanisms for reading & writting can have common or very similar API for using by netsniff-ng & trafgen.