Send lwip-devel mailing list submissions to
lip-devel@nongnu.orgw
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.nongnu.org/mailman/listinfo/lwip-devel
or, via email, send a message with subject or body 'help' to
lwip-devel-request@nongnu.org
You can reach the person managing the list at
lwip-devel-owner@nongnu.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of lwip-devel digest..."
Today's Topics:
1. Re: Query on Per-socket Locking and Optimal Performance Model
in lwIP (Simon Goldschmidt)
----------------------------------------------------------------------
Message: 1
Date: Tue, 5 Mar 2024 21:14:26 +0100
From: Simon Goldschmidt <goldsimon@gmx.de>
To: lwip-devel@nongnu.org
Subject: Re: [lwip-devel] Query on Per-socket Locking and Optimal
Performance Model in lwIP
Message-ID: <7910e676-1c87-4104-a3e9-e53f2bd4d292@gmx.de" target="_blank">7910e676-1c87-4104-a3e9-e53f2bd4d292@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 05.03.2024 06:29, 袁仲 wrote:
>> Dear lwIP Community, I hope this message finds you well.
> Yes, it found me twice. I wonder why you sent it twice?
Sorry, I sent first one before I reply the lwip-devel-confirm , I thougt you could not receive, so, I do the confirm stuff and sent another one.
>>
>> 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
>> <http://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?
> 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?
>> 2. What design pattern or model would best leverage lwIP's performance,
>> especially when handling multiple simultaneous socket interactions?
> 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,
> Simon
Regards,
Heavy
------------------------------
Subject: Digest Footer
_______________________________________________
lwip-devel mailing list
lwip-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
------------------------------
End of lwip-devel Digest, Vol 237, Issue 4
******************************************