From: Ursula Braun <ubraun@xxxxxxxxxxxxxxxxxx> Date: Wed, 22 Jul 2015 10:59:47 +0200 > 1. Provides optimized performance compared to standard TCP/IP over Ethernet > within the data center for both request/response (latency) and streaming > workloads (CPU savings) [3]. > Initial benchmarks on Linux on x86 processors have shown latency > reduction of up to 52% with a throughput gain of 111% using SMC-R vs TCP > for request/response message patterns (10 concurrent TCP connections > with 16KB messages) and CPU savings of up to 69% for streaming data > patterns (single TCP connection with 20MB of data in one direction). > [1] is currently updated to contain more detailed information on Linux > and performance. I'm really sorry but this is the same rabbit hole and set of claims that have been bullhorned my way for RDMA over the years and I still don't buy it. None of the RDMA'ish proponents ever talk about what you _don't_ get when this stuff triggers. No netfilter. No packet scheduler. No classifier actions. No BPF. No bridging. Basically, every single interesting feature of the Linux networking goes away once this RDMA thing happens. Furthermore the benchmarks are carefully choosen to exemplify the perfect environment for this feature to excell at. Sorry, I don't want any of this in our core networking stack. You'll have to support this completely outside of the TCP implementation and core networking code, and therefore have it %100 in your own separate module with your own can of worms like the Infiniband et al. people do. Having this standardized or "in widespread successful use" has no bearing upon the things I do not like about this patch set, so do not use those kinds of arguments to try and change my mind. It won't work. I'm not applying this patch series. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
