On Sat, Dec 21, 2024 at 04:34:25PM +0000, Bjoern A. Zeeb wrote: > On Tue, 17 Dec 2024, Mark Johnston wrote: > > > Lately I've been working on adding FIB awareness to bind(2) and inpcb > > lookup. > > Below I'll describe the project a bit. Any feedback/comments/suggestions > > would > > be appreciated. > > > > Today, a TCP or UDP socket can receive connections or datagrams from any > > FIB. > > SCTP?
SCTP has its own notion of a routing table index, the VRF, which is already supported in some form by our implementation. I don't know much about the details. It might be that SCTP already provides similar functionality. > > Any thoughts/comments? > > How much use are FIBs still these days? Half of the original use cases > I can think of could easily and better be overcome by using vnet jails > with a physical or virtual interface (e.g, vcc) being delegated to the > vnet. Certainly VNET jails provide equivalent functionality, but they have considerably higher overhead than separate FIBs. Moreover, they're less flexible than FIBs in that an application can only exist within a single VNET, whereas different sockets can be attached to different FIBs. > I wonder if anyone on FreeBSD is using FIBs to actually have multi-FIB > forwardig but that very little touches your use case apart from the mgmt > which again can be factored out better (or inversely, factoring out the > forwarding). > > I would honestly know who and how FIBs are still in use today or if they > should be put on a list to be removed for 16 (I assume I might be > surprised). FIBs are certainly in use by at least one FreeBSD-using company, but I don't have any real details. Removing them is probably not on the table in the near to medium-term future. > That all said with your opt-in approach if the code itself doesn't bring > too many new complications I'd be happy with it (assuming FIBs still > have a use case). > > /bz > > -- > Bjoern A. Zeeb r15:7
