Re: Enabling EXTRA_TCP_STACKS on stable/13

Hi Michael,

On Fri, Apr 22, 2022 at 08:36:42PM +0200, Michael Tuexen wrote:
> > On 22. Apr 2022, at 17:55, Gordon Bergling <gbe@FreeBSD.org> wrote:
> > I recently build some personal infrastructure and experimented a little
> > bit with tcp_bbr(4) and tcp_rack. Doing is this in a cloud environment
> > is a little bit priced since the kernel must be rebuild with the build
> > options EXTRA_TCP_STACKS defined.
> > 
> > Would it be feasable to switch this option to on by default?
> Wouldn't we also need
> options		TCPHTPS

Thats true, I could provide a differential that would cover this aswell.

> > I would think that the rack and bbr are stable enough for further
> > adoption.
> I would say we can do so for RACK in the master branch. Not sure about
> BBR, since it implements BBRv1, which is known to be unfair in some
> situations (this is not a property of the FreeBSD implementation,
> but of the algorithm).

I am not sure if this can be easly accomplished since I don't know
the implementation of the build switch. I just would reverse the build
switch so BBR and RACK would be available.

> I'm not sure about stable/13, since a lot of changes haven't been
> backported.

You are right about this. We should MFC all changes since we ship to
code already with a second RELEASE coming up. If we build both extra
stacks on -CURRENT a MFC could be set with an MFC-window from 
about 1-2 month.

> We can discuss this at the next transport conference call. Are you
> interested to join (scheduled for May 5th, 15:00 UTC)?

I could try to attent the call, but I am not sure if I could make in
time.

--Gordon