Re: [RFC v2 00/14] Generic TCP-option framework and adoption for TCP-SMC and TCP-MD5

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Christoph Paasch <cpaasch@xxxxxxxxx>
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.




[Index of Archives]     [Linux Kernel Discussion]     [TCP Instrumentation]     [Ethernet Bridging]     [Linux Wireless Networking]     [Linux WPAN Networking]     [Linux Host AP]     [Linux WPAN Networking]     [Linux Bluetooth Networking]     [Linux ATH6KL Networking]     [Linux Networking Users]     [XDP Newbies]     [Linux Coverity]     [VLAN]     [Git]     [IETF Annouce]     [Linux Assembly]     [Security]     [Bugtraq]     [Yosemite Information]     [MIPS Linux]     [ARM Linux Kernel]     [ARM Linux]     [Linux Virtualization]     [Linux IDE]     [Linux RAID]     [Linux SCSI]

  Powered by Linux