Hello, I think Kamailio is using for the UDP server the SO_REUSEADDR flag, which is somehow similar as the SO_REUSEPORT.
Kamailio is used in installation up to millions of customer devices. So, in many cases, the scaling challenges you are having are not related to Kamailio but to other infrastructure, e.g. a database or similar. I would suggest you setup a test environment for the performance requirements you are having and then doing some actual benchmarks. Cheers, Henning From: Sarju Garg <[email protected]> Sent: Donnerstag, 19. Februar 2026 11:09 To: Sergey Safarov <[email protected]> Cc: Kamailio (SER) - Development Mailing List <[email protected]>; [email protected]; Chandrabhan Kumar <[email protected]>; Henning Westerholt <[email protected]> Subject: Re: [sr-dev] Re: SO_REUSEPORT HI Sergey, Thanks. It supports connecting multiple child processes to a single UDP queue, but not sure if it does port reuse at UDP. There is a parameter for tcp_reuse_port. I understand if the tuple (src ip/port and Dest ip/port) is same, then there will be multiple consumers (connection parameter to create worker thread) . So multiple process will be waiting on single queue If I refer example in cook book , children=4 listen=udp:127.0.0.1:5080 listen=udp:127.0.0.1:5070 listen=udp:127.0.0.1:5060 4 children each would be created for 3 different ports, but in my case, it would be children=4 listen=udp:127.0.0.1:5080 As my IP / port is only one. However, I want 3 different queues to be created. As per the internet * SO_REUSEPORT: This socket option allows multiple threads or processes to bind to the same UDP port, each with its own socket and receive queue, which helps avoid contention on a single receive buffer lock in multi-core systems. Now since I have 3 different sources, I want to create 3 UDP queues with each having 4 consumers… I hope I can explain my problem, and hence using the SO_REUSEPORT option in UDP Regards Sarju But if src ip/port is different, like 3 src/ip sending to same dest ip/port,then 3 UDP queue is created and then multiple consumer will listen on 3 different queue. From: Sergey Safarov <[email protected]<mailto:[email protected]>> Date: Thursday, 19 February 2026 at 12:09 PM To: Sarju Garg <[email protected]<mailto:[email protected]>> Cc: "Kamailio (SER) - Development Mailing List" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Chandrabhan Kumar <[email protected]<mailto:[email protected]>>, Henning Westerholt <[email protected]<mailto:[email protected]>> Subject: Re: [sr-dev] Re: SO_REUSEPORT Kamailio supports port reuse. You just need to enable this feature in the config file and then start several Kamailio copies. For example using different systemd units. If I am not wrong, Kamailio supports distributing load to different processes forks on different cores. This is a present out of box and you do not need to do anything more. Just need to create additional UDP childrens. Sergey On Thu, Feb 19, 2026 at 1:23 AM Sarju Garg <[email protected]<mailto:[email protected]>> wrote: Hi, I am exploring REUSE_PORT Option for UDP. I am getting high TPS on single UDP port say 5060. Our customer will send the complete load from one IP and one port only. And from my side I have one IP and one port. As per my understanding in that case tuple antropy cannot be achieved so was thinking if REUSE_PORT. Can be done to have parallel queue and as per Linux document, the multiple queue on same port is created. My TPS requirement is about 20000 and try to see if how to architect the same. Regards Sarju From: Sergey Safarov <[email protected]<mailto:[email protected]>> Date: Wednesday, 18 February 2026 at 1:44 PM To: "Kamailio (SER) - Development Mailing List" <[email protected]<mailto:[email protected]>> Cc: Sarju Garg <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Chandrabhan Kumar <[email protected]<mailto:[email protected]>>, Henning Westerholt <[email protected]<mailto:[email protected]>> Subject: Re: [sr-dev] Re: SO_REUSEPORT for UTP transport all message to the same IP:PORT address use the same port when send via same socket. On Wed, Feb 18, 2026 at 9:31 AM Henning Westerholt via sr-dev <[email protected]<mailto:[email protected]>> wrote: Hello, please describe what you are wanting to achieve. When we are talking about re-using ports in the SIP Kamailio context, usually its about TCP connections. This is supported from Kamailio when activated in the core. Cheers, Henning -- Kamailio services – https://gilawa.com > -----Original Message----- > From: Sarju Garg <[email protected]<mailto:[email protected]>> > Sent: Mittwoch, 18. Februar 2026 03:57 > To: Federico Cabiddu > <[email protected]<mailto:[email protected]>> > Cc: Henning Westerholt <[email protected]<mailto:[email protected]>>; Kamailio > (SER) - Development > Mailing List <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; M S > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; Chandrabhan Kumar > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]> > Subject: SO_REUSEPORT > > Hi all, > > > I want a help to understand if the reuse port feature is supported in the UDP > sockets. > > > I tried to have a look into the code but could not find much detail, > > > The link provides the development information is available, but it does not > talk > about it. > > > > > Regards > Sarju > > _______________________________________________ Kamailio - Development Mailing List -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> Important: keep the mailing list in the recipients, do not reply only to the sender!
_______________________________________________ Kamailio - Development Mailing List -- [email protected] To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender!
