Hi all,
Recently I have some problems with Bro and PF_RING in cluster.
On my server, when I have less than 32 worker threads(rings), everything is okay, but when I use worker threads more than 32, pf_ring start to receive repeating data packets. For example, rings less than 32, I send 400000 packets to server and pf_ring info in /proc shows there is 400000 packets in rings, but when rings greater than 32, I can get 800000 packets when 33 rings and 1200000 packets when 34 rings and so on.
I guess if there is some rules that a pf_ring or a bro cluster can only support less than 32 rings or worker threads on a server or some other reasons?
Any insight would be helpful.
That sounds like an issue with PF_Ring. I would check their documentation and mailing list to see if they only support 32 rings.
.Seth
Hi all
there is a limit to the number of sockets in a pf_ring kernel cluster,
it used to be 32, now I increased it to 64 which I guess should be enough.
Alfredo
Hi all,
Thanks for your reply.
I found a definition in kernel/linux/pf_ring.h in PF_RING source code. The “CLUSTER_LEN” define the maximum of sockets a cluster can holds.
Now Im sure it is a issue with PF_RING. And I also increased "CLUSTER_LEN" to 64 and it seems like everything is okay. But I
m still confuse about why the limit set to 32 and whether it is right to modify the source code. Will it affect the stability of PF_RING and Bro?
Bowen
Hi Li,
I met the same problem as you. Have you solved it? I also wonder whether modifying this macro definition CLUSTER_LEN correct, and whether it will affect stability of the system, did you get any idea after this reply?
I had this issue previously. Probably best to just move from pfring to AF Packet (https://packages.zeek.org/packages/view/cc6aec82-9348-11eb-81e7-0a598146b5c6). That is what fixed it for me … and gave me a much better performance.
There is also a plugin in development for DPDK (https://github.com/esnet/dpdk-plugin), which has the potential to be even better, but this plugin is still in early development, I think.
Kurtis