From: David Miller <davem@davemloft.net>
To: cpaasch@apple.com
Cc: netdev@vger.kernel.org, edumazet@google.com,
mathew.j.martineau@linux.intel.com
Subject: Re: [RFC v2 00/14] Generic TCP-option framework and adoption for TCP-SMC and TCP-MD5
Date: Thu, 01 Feb 2018 10:15:46 -0500 (EST) [thread overview]
Message-ID: <20180201.101546.1130189794958826633.davem@davemloft.net> (raw)
In-Reply-To: <20180201000716.69301-1-cpaasch@apple.com>
From: Christoph Paasch <cpaasch@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
properly.
And now we're going to do indirect calls to callbacks instead of
inline tests as well?
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 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.
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.
next prev parent reply other threads:[~2018-02-01 15:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 0:07 [RFC v2 00/14] Generic TCP-option framework and adoption for TCP-SMC and TCP-MD5 Christoph Paasch
2018-02-01 0:07 ` [RFC v2 01/14] tcp: Write options after the header has been fully done Christoph Paasch
2018-02-01 0:07 ` [RFC v2 02/14] tcp: Pass sock and skb to tcp_options_write Christoph Paasch
2018-02-01 15:11 ` David Miller
2018-02-01 0:07 ` [RFC v2 03/14] tcp: Allow tcp_fast_parse_options to drop segments Christoph Paasch
2018-02-01 0:07 ` [RFC v2 04/14] tcp_smc: Make smc_parse_options return 1 on success Christoph Paasch
2018-02-01 0:07 ` [RFC v2 05/14] tcp: Register handlers for extra TCP options Christoph Paasch
2018-02-01 0:07 ` [RFC v2 06/14] tcp_smc: Make SMC use TCP extra-option framework Christoph Paasch
2018-02-01 0:07 ` [RFC v2 07/14] tcp_md5: Don't pass along md5-key Christoph Paasch
2018-02-01 0:07 ` [RFC v2 08/14] tcp_md5: Detect key inside tcp_v4_send_ack instead of passing it as an argument Christoph Paasch
2018-02-01 0:07 ` [RFC v2 09/14] tcp_md5: Detect key inside tcp_v6_send_response " Christoph Paasch
2018-02-01 0:07 ` [RFC v2 10/14] tcp_md5: Check for TCP_MD5 after TCP Timestamps in tcp_established_options Christoph Paasch
2018-02-01 0:07 ` [RFC v2 11/14] tcp_md5: Move TCP-MD5 code out of TCP itself Christoph Paasch
2018-02-01 0:07 ` [RFC v2 12/14] tcp_md5: Use tcp_extra_options in output path Christoph Paasch
2018-02-01 0:07 ` [RFC v2 13/14] tcp_md5: Cleanup TCP-code Christoph Paasch
2018-02-01 0:07 ` [RFC v2 14/14] tcp_md5: Use TCP extra-options on the input path Christoph Paasch
2018-02-01 15:15 ` David Miller [this message]
2018-02-03 1:15 ` [RFC v2 00/14] Generic TCP-option framework and adoption for TCP-SMC and TCP-MD5 Christoph Paasch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180201.101546.1130189794958826633.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=cpaasch@apple.com \
--cc=edumazet@google.com \
--cc=mathew.j.martineau@linux.intel.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).