I think this breaks the ABI and makes the change a non-MFCable.

It looks like key_spidxhash() is similar to key_saidxhash(). Maybe it makes sense to rework it like:

static uint32_t key_addrprotohash(const union sockaddr_union *src, const union sockaddr_union *dst,
     const uint8_t *proto);

#define SPDCACHE_HASHVAL(idx)  \
     (key_addrprotohash(&idx->src, &idx->dst, &idx->ul_proto) & V_spdcachehash_mask)
#define SAHADDRHASH_HASHVAL(idx)   \
     (key_addrprotohash(&idx->src, &idx->dst, &idx->proto) & V_sahaddrhash_mask)

This confuses the reader, I think it is better to not hide & under the macro. Also it is not clear to me, why we can not just use NULL pointer for this purpose.

I think this should be SYSCTL_PROC to correctly handle user's input.

hashinit() already did LISTs initialization.

Yes indeed. Is it a problem to be non-MFCable?

Yes you're right. This is some old code from the first version of this cache, NULL is ok for the purpose.

I am not sure to understand what you mean.
Do you mean it is badly handled (bug?) or would you like the cache size to be changed during runtime?

I meant that user can specify wrong values and it is bad. I'm not sure that value 8 or 9 is good enough to test the cache. Ah, I understand, SYSCTL_PROC is wrong suggestion, since it is RDTUN, I meant that we need to check the value and probably do not accept values that are below some default.

A small cache would be probably inefficient, but how can we decide the minimum size to be set? Do you have suggestions? 128, 1024, ...?

8 would be probably OK if you have a huge SPD but very few traffic flows involved at the same time (a huge SPD usually means many different traffic flows though)

Just to make sure: you want to remove ips_mbcoalesced and ips_clcoalesced?

Yes, they seem to be unused.