tcp_hostcache: add sysctl function for updating the hostcache

[rscheff]

Summary

While investigating PR296474 it was found that some parameters
picked up from the hostcache are essential to reproduce the behavior
of the TCP stack.

No facilities existed to load and manipulate the hostcache entries
before, making it difficult to populate and prepare the initial
state exactly alike to the problematic scenario.

This refactories the update function which walks the hostcache or
finds the most pertinent entry to overwrite with support for a callback
function. The old update function is then a wrapper with the middle
section put in a dedicated function, where the values derived from the
stack get inserted into the host cache.

Secondly, a custom sysctl interface with a simple parser is provided
to allow the explicit modification of enties and subsets of values.

Usage:
sysctl net.inet.tcp.hostcache.update=::1,1460,,10,500,60000,20000,10000,1000

The order is the same as with net.inet.tcp.hostcache.list. The initial IPv4
or IPv6 address is mandatory. Subsequent values can be skipped (,,), set to
a specific number (RTT and RTTvar operate at ms granularity, not the internal
representation), or increase/descrease with signed numbers like +100 or -200.

[glebius]

This is definitely a useful functionality but the implementation will raise concerns from developers outside of network stack area. We don't want to add string parsing procedures to the kernel.

The correct implementation should use a binary API and string parsing should happen in the userspace. The tcpdrop(8) seems like a nice place to add this functionality to avoid a new utility.

[glebius]

You may add the patch as is under some non-default ifdef.

P.S. Do you have a shared branch with all of your changes to the hostcache? I have a long lived branch (2 years) that has some improvements to it and I want to see if I can rebase on top of your work. I actually plan to push it to FreeBSD in September.

[rscheff]

In D58358#1338485, @glebius wrote:

This is definitely a useful functionality but the implementation will raise concerns from developers outside of network stack area. We don't want to add string parsing procedures to the kernel.

The correct implementation should use a binary API and string parsing should happen in the userspace. The tcpdrop(8) seems like a nice place to add this functionality to avoid a new utility.

How about bringing more fancy parsing capabilities and construction of struct-type binary blobs properly into sysctl then?
However, the current functionality (skipping over fields and retaining them, or adjusting other fields relative to the current value) would not be available any more.
The rudimentary facilities of sysctl to support binary blobs - when I tried to do something useful with it - were not actually doing anything properly in my recollection.

[rscheff]

I found that there is actual precedence in sysctl to have custom handling code for CTL_OPAQUE datastructures there - from very long ago (checked in 24 yrs ago).

I will take the parser code and put it into sysctl, with a special handler - while keeping the MTU sanity checks in the SYSCTL_PROC handler in the kernel. This should allow to maintain the same functionality, and also properly display the before / after enties.