Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:  +176 +0.019% RPI_PICO_W[incl +176(bss)]
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Thanks for the contribution.

Despite the code comments claiming one is sufficient

Can you point to where the comment says one is sufficient? I could not find it.

Three per IP protocol are started at once per IP protocol in mdns_start_multicast_timeouts_ipvX,

Yes, that looks correct, I can see 3 independent timers in those functions.

then another two per protocol can be started in mdns_set_timeout.

I don't follow this bit, because mdns_set_timeout is a helper function. I think you meant to say this is called from mdns_handle_question()? Then the 5 timers per protocol are:

• multicast_timeout
• multicast_probe_timeout
• multicast_timeout_25TTL
• unicast_msg_in_use
• multicast_msg_waiting

And it definitely looks possible to have all 5 of those running at once.

But then there are also additional calls to sys_timeout() in src/apps/mdns/mdns.c:

2164:      sys_timeout(MDNS_RESPONSE_TC_DELAY_MS, mdns_handle_tc_question, pkt);
2319:        sys_timeout(MDNS_PROBE_MAX_CONFLICTS_TIMEOUT, mdns_probe_and_announce, netif);
2322:        sys_timeout(MDNS_PROBE_DELAY_MS, mdns_probe_and_announce, netif);
2348:        sys_timeout(announce_delay, mdns_probe_and_announce, netif);
2786:    sys_timeout(MDNS_PROBE_MAX_CONFLICTS_TIMEOUT, mdns_probe_and_announce, netif);
2790:    sys_timeout(delay, mdns_probe_and_announce, netif);

I'm not sure how to work out which of those can be running together... and in fact those calls could start an arbitrary number of timers if they are called over and over again. But, since there are only two independent callbacks (namely mdns_handle_tc_question and mdns_probe_and_announce) it seems sensible to allow just two timers for these calls. So maybe there needs to be 2 + 5 * (IP4+IP6) timers in total?

(Also, please check the CI code formatting failure.)

Thanks for checking my work and the quick response.

Can you point to where the comment says one is sufficient? I could not find it.

Line 11 of src/apps/mdns/mdns.c says "You need to increase MEMP_NUM_SYS_TIMEOUT by one if you use MDNS!" I do not know why the number of timers has expanded so dramatically, it's not a super old comment.

I don't follow this bit, because mdns_set_timeout is a helper function. I think you meant to say this is called from mdns_handle_question()? Then the 5 timers per protocol are:
...

Sorry, yes I mis-pasted the function name when writing the message. Those are the same 5 timers I identified.

But then there are also additional calls to sys_timeout() in src/apps/mdns/mdns.c:

I missed these, thank you. It looks like these are used in rarer circumstances, but I agree with your assessment that these could take arbitrary numbers of timers. It is unfortunate that each callback could be queued several times and use up the timer slots for the other processes. I think upstream might need to put some attention here.

I could send an inquiry to their list but I don't think I have bandwidth to fix it up at this time.

(Also, please check the CI code formatting failure.)

I will increase the number of timers and address the failure and test again.

Okay, took a few tries but I think we are good now!

Thanks for updating.

In order to eliminate code duplication, I made PR #16647 which factors out the common lwIP configuration for these four ports. I think we should merge that first, then this PR becomes simpler, it's just changing one location.

@tpwrules are you able to update this PR and just make a single change in the consolidated file at extmod/lwip-include/lwipopts_common.h?

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.53%. Comparing base (842e361) to head (aef6705).
Report is 1 commits behind head on master.

@@           Coverage Diff           @@
##           master   #16623   +/-   ##
=======================================
  Coverage   98.53%   98.53%           
=======================================
  Files         169      169           
  Lines       21806    21806           
=======================================
  Hits        21487    21487           
  Misses        319      319           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Not sure what to do about the CI failure?

Not sure what to do about the CI failure?

I reran it, it now passes.

CircuitPython has had similar problems with static memory pool allocations in lwIP. Our solution was to configure lwIP to allocate all of its memory dynamically from our top-level tlsf heap. See adafruit#9837.

Thanks for updating, now merged.