Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The highest performance at packet forwarding #450

Open
ZlobinDA opened this issue Jan 20, 2025 · 2 comments
Open

The highest performance at packet forwarding #450

ZlobinDA opened this issue Jan 20, 2025 · 2 comments

Comments

@ZlobinDA
Copy link

Hello! I'm working on an AF_XDP application that receives packets on the eth0 interface, processes them, and then sends them out on the eth1 interface. Essentially, it forwards packets from eth0 to eth1. The application uses two physical interfaces and a CPU with approximately 30 cores. I want to achieve the highest possible performance from this application.

I would appreciate it if you could comment on which of the following approaches is the most suitable from an eBPF perspective:

  1. Run several single-threaded AF_XDP applications on the interfaces.
  2. Create multiple sockets on the interface within a single application, with each socket running in a separate thread, and the sockets sharing a common UMEM.
  3. Run multiple threads for packet processing within a single application. It seems to me that this approach is slower than options 1 and 2, as packet processing does not involve heavy logic.

Thank you!

@ZlobinDA
Copy link
Author

@magnus-karlsson excuse me for bothering you, could you please help me?

@magnus-karlsson
Copy link
Member

Hi,

Please take a look at the AF_XDP-forwarding example in the bpf-examples repo (https://github.com/xdp-project/bpf-examples.git). It exemplifies 2 and 3 above. BTW, 3 is not slower but it is a lot simpler since you are sharing the same memory space between the threads located in the same process space. This makes sharing the umem a breeze, while it is, comparably, quite complicated in 1. So I would skip 1 to start with. The pros of 1 are isolation and security which you do not need unless this is a serious application that you are writing. You could always change this afterwards in any case without changing your data path logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants