From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller 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) Message-ID: <20180201.101546.1130189794958826633.davem@davemloft.net> References: <20180201000716.69301-1-cpaasch@apple.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, edumazet@google.com, mathew.j.martineau@linux.intel.com To: cpaasch@apple.com Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:44574 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751378AbeBAPPs (ORCPT ); Thu, 1 Feb 2018 10:15:48 -0500 In-Reply-To: <20180201000716.69301-1-cpaasch@apple.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Christoph Paasch 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.