Date: Sat, 21 Dec 2024 13:55:49 -0500 From: Mark Johnston <markj@freebsd.org> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-net@freebsd.org Subject: Re: per-FIB socket binding Message-ID: <Z2cPNQT6eAS8l_ff@nuc> In-Reply-To: <4p5o59s4-5p70-0775-1479-990o1s5po7r2@yvfgf.mnoonqbm.arg> References: <Z2G_q5s35AremgYc@nuc> <4p5o59s4-5p70-0775-1479-990o1s5po7r2@yvfgf.mnoonqbm.arg>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Z2cPNQT6eAS8l_ff>