This introduces an additional dependency on lru, but that package is already used elsewhere in Mirage already (e.g. mirage-tcpip), so it usually wouldn't affect the dependency list of a unikernel.

Thanks for your contribution. With this, we store dynamic entries both in the map and in the LRU, is this correct? Certainly the runtime of retrieving an element then only needs to lookup in the map, but we have to keep the LRU and the map in sync. Is this worth it? Another approach would be to keep the map for static entries, and use the LRU for dynamic entries... Did you consider (and benchmark)?

Thanks for your contribution. With this, we store dynamic entries both in the map and in the LRU, is this correct? Certainly the runtime of retrieving an element then only needs to lookup in the map, but we have to keep the LRU and the map in sync. Is this worth it?

module M is intended to be a drop-in replacement for the old module M. I thought about using just the LRU (using a weight of 0 for static entries), but the problem is the 'a parameter to Arp_handler.t: LRU.F expects a type t, not a type 'a t. It might be possible to hide that with first class modules/GADTs, but I haven't tried yet.

Or maybe it'd be easier to make the lru library have polymorphic maps, but that'd also require changing psq potentially.
I haven't looked in detail, but I'd rather keep the code simpler by not attempting to store the 'a in the LRU.
(extending lru/psq might still be useful to make them easier to use in other projects too, I can look into that)

Another approach would be to keep the map for static entries, and use the LRU for dynamic entries... Did you consider (and benchmark)?

I don't think it'd change the lookup time (which I expect to matter most for performance). Adding/removing entries is rarer (only when talking to a new host).

Another approach would be to remove the 'a parameter from Arp_handler itself, but that'd potentially change arp's external API, and make it Lwt specific, which wouldn't be desirable.

There is already a timeout for the dynamic entries, so this can be used as a crude approximation instead of the LRU.
I thought about using a hot/cold map (with perhaps the cold map being LRU, and the hot map just a regular one), and there would also be other algorithms like Clock or Clock-Pro, segmented LRU, LIRS, etc.

But for now lets keep it simple.

I haven't benchmarked yet, but there is now only a single map lookup on the main query path, and no extra mutation/updates. For now I left the previous approach in the commit history, so we can compare all 3 impl (original, LRU and this one).

I probably also need to add a few more tests that uses the new invariant function.

Hmmhmm, I prefer the version with lru which is a well implemented library. Also, lru is used in many places into the MirageOS ecosystem (specially for mirage-tcpip). The previous diff seems more clear for me than the timeout one.

Thanks @edwintorok. I cherry-picked the first commit to the main branch.