On 01/02/18 - 10:15:46, David Miller wrote:
> From: Christoph Paasch <cpaa...@apple.com>
> Date: Wed, 31 Jan 2018 16:07:02 -0800
> > TCP-options like TCP_MD5 and SMC are rather rare use-cases, but their
> > implementation is rather intrusive to the TCP-stack. Other, more recent
> > TCP extensions like TCP-crypt, MPTCP or TCP-AO would make this situation
> > even worse.
> Yet, this current implementation is what allows us to optimize things
> And now we're going to do indirect calls to callbacks instead of
> inline tests as well?
Wrt to the potential performance impact, we have considered using static
keys that would only be enabled if one socket is using an option that is
part of the framework. That way the framework shouldn't cause any
performance issues as long as nobody uses these less common options.
Would that be an option to alleviate such concerns?
Or is your concern here that we are impacting the performance of TCP-MD5?
If it's the latter, we indeed are intentionally trading performance of
TCP-MD5 for a general "cleaner" TCP-stack (one that has no if-statements
for seldom used TCP-options like SMC and MD5). We thought the gain was worth
the cost, which can be arguable of course.
> Also, requiring such direct surgery for new TCP options forces the
> developer to consider the consequences of what the new TCP option
> does and how it effect both the slow and the fast path.
> With abstraction layers, people tend to turn their brains off when
> it comes to these issues.
> Sorry, I'm really not thrilled about this.
I can see your point and the risk that the abstraction layer brings, but let
me try to clarify what we think the framework would enable:
Our goal with the framework is to optimize/design for the common-case while
allowing extensibility and less common features.
That way we can keep the TCP-stack clean with the most-used TCP-options (SACK,
Timestamps,...), while still allowing the more exotic features like MD5. And
only sockets that enable TCP-MD5 will pay the potential performance price for
And for new options, the framework forces people to think about how to make the
feature work without spreading if-statements across the stack.
If the new option becomes the common-case after some time, it can always be
integrated into the stack at that moment.
> I would rather see the new TCP option features be proposed using
> the existing code and then see how it all can be abstracted away
> after they are all added.
Would a possible path forward be that we rather post the patches that
cleanup the TCP-MD5 code.
(meaning roughly patches 7 to 14 but without the option-framework adoption)
That way, we cleanup the TCP-stack at least by factoring out TCP-MD5.
> I can already see in your patches that new overhead is added, new
> tests in the packet building fast paths that are completely
> unnecessary with the existing code, etc.
Point taken, we will double-check our impact on the fast-path and make sure
to change that.
Thanks for your feedback!