option TCP_RFC7413 is not in GENERIC

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

option TCP_RFC7413 is not in GENERIC

Mark Felder
Hello all,

Has there been a discussion about enabling this in GENERIC? Is there a performance impact even if the sysctl knob is disabled? What can we do to get a wider audience of testers? I would gladly test this for apps that support it but the hurdle of requiring a custom kernel to test this is more effort than its worth...


Thanks


--
  Mark Felder
  ports-secteam & portmgr member
  [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: option TCP_RFC7413 is not in GENERIC

Herbert J. Skuhra-8
On Wed, Mar 14, 2018 at 04:13:48PM -0500, Mark Felder wrote:
> Hello all,
>
> Has there been a discussion about enabling this in GENERIC? Is there a performance impact even if the sysctl knob is disabled? What can we do to get a wider audience of testers? I would gladly test this for apps that support it but the hurdle of requiring a custom kernel to test this is more effort than its worth...


https://svnweb.freebsd.org/base?view=revision&revision=330002

--
Herbert
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: option TCP_RFC7413 is not in GENERIC

Patrick Kelsey-2
On Wed, Mar 14, 2018 at 7:39 PM Herbert J. Skuhra <[hidden email]> wrote:

> On Wed, Mar 14, 2018 at 04:13:48PM -0500, Mark Felder wrote:
> > Hello all,
> >
> > Has there been a discussion about enabling this in GENERIC? Is there a
> performance impact even if the sysctl knob is disabled? What can we do to
> get a wider audience of testers? I would gladly test this for apps that
> support it but the hurdle of requiring a custom kernel to test this is more
> effort than its worth...
>
>
> https://svnweb.freebsd.org/base?view=revision&revision=330002
>
>
I plan on merging all of the TFO deltas between current and stable/11 to
stable/11 ahead of the 11.2 release process.  tuexen@ has been doing some
good bug hunting on the new client-side implementation in -current and
there are other parties testing it as well.  I think there is still
technically a question as to whether it will be enabled by default in 11.2,
only because there is still some poking and prodding we have left to do,
but I also think we will complete all of that in time.

As to performance impact when it is compiled in, but disabled, I have heard
that some small differences have been measured, but I've seen neither the
methodology used nor the actual measurement results.  Mechanically what is
going on in that case is you will wind up with some additional flag checks
in the TCP input and output paths and in some cases additional instructions
that you don't need being pulled into the I-cache, compared to what would
occur if it was compiled out.  The current thinking is that users who care
about such performance differences are dealing with extreme workloads that
already motivate them to compile their own kernels, or are working with
very resource-constrained platforms, so the way forward is to keep the
TCP_RFC7413 kernel option around and enable it by default for the
server-class platforms (armd64 and arm64).

Best,
Patrick
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: option TCP_RFC7413 is not in GENERIC

Ian Lepore-3
On Fri, 2018-03-16 at 16:04 +0000, Patrick Kelsey wrote:
> The current thinking is that users who care
> about such performance differences are dealing with extreme workloads that
> already motivate them to compile their own kernels, or are working with
> very resource-constrained platforms, so the way forward is to keep the
> TCP_RFC7413 kernel option around and enable it by default for the
> server-class platforms (armd64 and arm64).

I have no idea what TCP_RFC7413 even is, but I know I was forced to add
it to my kernel config when I installed the bind911 package during a
recent upgrade.  This is on a tiny NUC for which saturating even one of
its gbe interfaces would count as "extreme workload". :)

-- Ian
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: option TCP_RFC7413 is not in GENERIC

Patrick Kelsey-2
On Fri, Mar 16, 2018 at 12:12 PM Ian Lepore <[hidden email]> wrote:

> On Fri, 2018-03-16 at 16:04 +0000, Patrick Kelsey wrote:
> > The current thinking is that users who care
> > about such performance differences are dealing with extreme workloads
> that
> > already motivate them to compile their own kernels, or are working with
> > very resource-constrained platforms, so the way forward is to keep the
> > TCP_RFC7413 kernel option around and enable it by default for the
> > server-class platforms (armd64 and arm64).
>
> I have no idea what TCP_RFC7413 even is, but I know I was forced to add
> it to my kernel config when I installed the bind911 package during a
> recent upgrade.  This is on a tiny NUC for which saturating even one of
> its gbe interfaces would count as "extreme workload". :)
>
>
RFC7413 is TCP Fast Open (TFO), which is a way to short-circuit TCP
handshakes if <mumble> conditions are met.  I'm curious as to why you were
forced to add the option to your kernel config when you installed bind911.
Maybe that version of bind was assuming something like 'if the TCP_FASTOPEN
sockopt is defined in a header, then all setsockopt(TCP_FASTOPEN) should
succeed or else die'?  That would be a very weird assumption, as the MacOS,
Linux, and FreeBSD implementations all have a sysctl that can be used to
disable the feature system-wide at any point in time.

-Patrick
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: option TCP_RFC7413 is not in GENERIC

Matthew D. Fuller
On Fri, Mar 16, 2018 at 04:42:10PM +0000 I heard the voice of
Patrick Kelsey, and lo! it spake thus:
>
> I'm curious as to why you were forced to add the option to your
> kernel config when you installed bind911.

I suspect it's not quite "forced to", but you otherwise have to ignore
all the squawcking it does every time it starts up about failing to
set the option on all its sockets...

(me, I moved past ignoring it to taking perverse pleasure in it.
Haha, silly daemon.  You brought this on yourself, so now you must
suffffaaaahhhh...)


--
Matthew Fuller     (MF4839)   |  [hidden email]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: option TCP_RFC7413 is not in GENERIC

Ian Lepore-3
In reply to this post by Patrick Kelsey-2
On Fri, 2018-03-16 at 16:42 +0000, Patrick Kelsey wrote:

> On Fri, Mar 16, 2018 at 12:12 PM Ian Lepore <[hidden email]> wrote:
>
> >
> > On Fri, 2018-03-16 at 16:04 +0000, Patrick Kelsey wrote:
> > >
> > > The current thinking is that users who care
> > > about such performance differences are dealing with extreme workloads
> > that
> > >
> > > already motivate them to compile their own kernels, or are working with
> > > very resource-constrained platforms, so the way forward is to keep the
> > > TCP_RFC7413 kernel option around and enable it by default for the
> > > server-class platforms (armd64 and arm64).
> > I have no idea what TCP_RFC7413 even is, but I know I was forced to add
> > it to my kernel config when I installed the bind911 package during a
> > recent upgrade.  This is on a tiny NUC for which saturating even one of
> > its gbe interfaces would count as "extreme workload". :)
> >
> >
> RFC7413 is TCP Fast Open (TFO), which is a way to short-circuit TCP
> handshakes if  conditions are met.  I'm curious as to why you were
> forced to add the option to your kernel config when you installed bind911.
> Maybe that version of bind was assuming something like 'if the TCP_FASTOPEN
> sockopt is defined in a header, then all setsockopt(TCP_FASTOPEN) should
> succeed or else die'?  That would be a very weird assumption, as the MacOS,
> Linux, and FreeBSD implementations all have a sysctl that can be used to
> disable the feature system-wide at any point in time.
>
> -Patrick

Oh, then I assume it's because TCP_FASTOPEN is in the default options
when the package gets built.

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: option TCP_RFC7413 is not in GENERIC

Ian Lepore-3
In reply to this post by Matthew D. Fuller
On Fri, 2018-03-16 at 12:24 -0500, Matthew D. Fuller wrote:

> On Fri, Mar 16, 2018 at 04:42:10PM +0000 I heard the voice of
> Patrick Kelsey, and lo! it spake thus:
> >
> >
> > I'm curious as to why you were forced to add the option to your
> > kernel config when you installed bind911.
> I suspect it's not quite "forced to", but you otherwise have to
> ignore
> all the squawcking it does every time it starts up about failing to
> set the option on all its sockets...
>
> (me, I moved past ignoring it to taking perverse pleasure in it.
> Haha, silly daemon.  You brought this on yourself, so now you must
> suffffaaaahhhh...)
>
>

I vaguely remember that dire-looking messages in syslog is what
"forced" me to build a new kernel, probably because it wasn't clear
that they could be safely ignored.

-- Ian
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: option TCP_RFC7413 is not in GENERIC

Mark Felder
In reply to this post by Ian Lepore-3


On Fri, Mar 16, 2018, at 11:11, Ian Lepore wrote:

> On Fri, 2018-03-16 at 16:04 +0000, Patrick Kelsey wrote:
> > The current thinking is that users who care
> > about such performance differences are dealing with extreme workloads that
> > already motivate them to compile their own kernels, or are working with
> > very resource-constrained platforms, so the way forward is to keep the
> > TCP_RFC7413 kernel option around and enable it by default for the
> > server-class platforms (armd64 and arm64).
>
> I have no idea what TCP_RFC7413 even is, but I know I was forced to add
> it to my kernel config when I installed the bind911 package during a
> recent upgrade.  This is on a tiny NUC for which saturating even one of
> its gbe interfaces would count as "extreme workload". :)
>

Funny, BIND911 is what sent me down this rabbit hole as well.


Thanks for the feedback and information, all! Look forward to these improvements :-)


--
  Mark Felder
  ports-secteam & portmgr member
  [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"