Re: per-FIB socket binding

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