lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] Query on Per-socket Locking and Optimal Performance Mod


From: 袁仲
Subject: Re: [lwip-devel] Query on Per-socket Locking and Optimal Performance Model in lwIP
Date: Mon, 11 Mar 2024 19:18:11 +0800

Hi there,

> Are you talking about sockets or about pcbs? Because there should be no
> problems using different sockets from different threads. You do have the
> "only one thread in core lwIP" rule, so performance is not great on
> multi-core systems in that case. That's the downside of staying
> "lightweight" so far (the "lw" in lwIP).
Thanks for your reply. 
Yes, I use different sockets from  different threads. But when I  use one socket from different threads.
The big lock in lwip stack impacts the system's overall performance, I was wondering if I should use per-socket (or pcb) lock,
and I practise it based on current lwip stack arch and get dead-lock.  This may  need lwip stack native support, I think.
Does the  lwip stack have plans to  support per-socket(or pcb) lock feature in the future?

> I don't think there has been public work in this area, so you're welcome
> to provide anything if you come up with something. I could imagine
> reader/writer locks, reference counting and many more. But up to now,
> noone really had enough interest in this area to actually implement
> this. I don't think it's a simple task to get that right!
Perhaps implementing per-socket lock is not a bad idea.



 Regards,
 Heavy 



On Tue, Mar 5, 2024 at 1:29 PM 袁仲 <yzlyourself@gmail.com> wrote:
Dear lwIP Community, I hope this message finds you well. 

I am Heavy, and I have been working on a user-space network component built upon the lwIP library version 2.1.3-stable.In my recent project experiences, it appears that lwIP(both version 2.1.13 and 2.2.0) does not inherently support per-socket locking. To address synchronization issues, I've resorted to using either the core tcpip lock provided by lwIP or creating custom mutexes to safeguard against concurrent access to both the lwIP stack operations and individual socket manipulations. This approach is functional, but I anticipate potential performance degradation in scenarios where multiple sockets are concurrently active, as these locks are essentially global to all socket operations.
My question is twofold:
1. Does the current stable release of lwIP indeed lack native support for per-socket locking mechanisms?
2. What design pattern or model would best leverage lwIP's performance, especially when handling multiple simultaneous socket interactions?

I appreciate any insights you can offer into this matter, as they will be instrumental in guiding me towards an efficient solution for enhancing concurrency and overall performance within my project.

Thank you in advance for your assistance and expertise.

Best Regards, Heavy

reply via email to

[Prev in Thread] Current Thread [Next in Thread]