[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180201.101546.1130189794958826633.davem@davemloft.net>
Date: Thu, 01 Feb 2018 10:15:46 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: cpaasch@...le.com
Cc: netdev@...r.kernel.org, edumazet@...gle.com,
mathew.j.martineau@...ux.intel.com
Subject: Re: [RFC v2 00/14] Generic TCP-option framework and adoption for
TCP-SMC and TCP-MD5
From: Christoph Paasch <cpaasch@...le.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.
Powered by blists - more mailing lists