buglwIP - A Lightweight TCP/IP stack - Bugs: bug #59492, mDNS: mdns_handle_questions holds...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #59492: mDNS: mdns_handle_questions holds core lock for excessive amount of time

Submitter:  Thomas Kindler <thomask77>
Submitted:  Fri 20 Nov 2020 12:05:50 PM UTC
   
 
Category:  apps Severity:  3 - Normal
Item Group:  Change Request Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
lwIP version:  git head

Tue 20 Apr 2021 09:03:50 AM UTC, comment #2: 

One solution would be an abstraction layer between the mDNS protocol and the netconn/raw callback-API. So if an operating system is available, mDNS could run in its own task.

But before we do that, we should make an detailed analysis, why it's so slow in the first place.. maybe there's a hidden performance bug.

Thomas Kindler <thomask77>
Mon 30 Nov 2020 09:58:23 PM UTC, comment #1: 

lwIP (and the mdns responder) also runs on systems without an operating system, and then netconn and tasks are not available.

I am not sure if there is a way to offload it in case an operating system is available.

Maybe the situation can be slightly improved also by limiting the parsing of incoming packets, depending on the mdns state and the type of packet. For instance, it might be possible to stop parsing answers heard once the mdns state is stable - unless that breaks the collision detection, I would have to check the details.

Erik Ekman <yarrick>
Group Member
Fri 20 Nov 2020 12:05:50 PM UTC, original submission:  

Hi!

We have a network with lots of mDNS traffic.

While most requests are handled quickly, we see that the mdns_handle_questions() sometimes takes multiple milliseconds to loop over the questions and answers.

Because this is done in a upd_recv() callback, all this complex processing is done while the core is locked.

This leads to other problems within our application, where we have strict < 1ms real-time requirements.

Perhaps, one solution would be to move mDNS processing into a dedicated, low-priority mDNS task using the netconn API.

Thomas Kindler <thomask77>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by yarrick (Posted a comment)
  • -email is unavailable- added by thomask77 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code