All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: ubraun@linux.vnet.ibm.com
Cc: utz.bacher@de.ibm.com, netdev@vger.kernel.org,
	linux-s390@vger.kernel.org, schwidefsky@de.ibm.com,
	heiko.carstens@de.ibm.com, ursula.braun@de.ibm.com
Subject: Re: [PATCH V3 net-next 0/5] net: implement SMC-R solution
Date: Sun, 26 Jul 2015 16:15:30 -0700 (PDT)	[thread overview]
Message-ID: <20150726.161530.2192841818929026804.davem@davemloft.net> (raw)
In-Reply-To: <1437555592-16506-1-git-send-email-ubraun@linux.vnet.ibm.com>

From: Ursula Braun <ubraun@linux.vnet.ibm.com>
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.

  parent reply	other threads:[~2015-07-26 23:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-14 12:42 [PATCH V2 net-next 0/3] net: implement SMC-R solution Ursula Braun
2015-07-14 12:42 ` [PATCH V2 net-next 1/3] tcp: introduce TCP experimental option for SMC Ursula Braun
2015-07-16  4:28   ` David Miller
2015-07-22  8:59     ` [PATCH V3 net-next 0/5] net: implement SMC-R solution Ursula Braun
2015-07-22  8:59       ` [PATCH V3 net-next 1/5] tcp: TCP experimental option for SMC - definitions Ursula Braun
2015-07-22  8:59       ` [PATCH V3 net-next 2/5] tcp: TCP experimental option for SMC - TCP hooks Ursula Braun
2015-07-22  8:59       ` [PATCH V3 net-next 3/5] net: introduce socket family constants Ursula Braun
2015-07-22  8:59       ` [PATCH V3 net-next 4/5] smc: introduce socket family AF_SMC Ursula Braun
2015-07-22  8:59       ` [PATCH V3 net-next 5/5] smc: increase / decrease static key Ursula Braun
2015-07-26 23:15       ` David Miller [this message]
2015-07-31 19:04         ` [PATCH V3 net-next 0/5] net: implement SMC-R solution Ursula Braun
2015-08-21 11:30         ` [PATCH V4 net-next 0/2] " Ursula Braun
2015-08-21 11:30           ` [PATCH V4 net-next 1/2] net: introduce socket family constants Ursula Braun
2015-08-21 11:30           ` [PATCH V4 net-next 2/2] smc: introduce socket family AF_SMC Ursula Braun
2015-08-25 18:18           ` [PATCH V4 net-next 0/2] net: implement SMC-R solution David Miller
2015-07-14 12:42 ` [PATCH V2 net-next 2/3] net: introduce socket family constants Ursula Braun
2015-07-16  4:29   ` David Miller
2015-07-14 12:42 ` [PATCH V2 net-next 3/3] smc: introduce socket family AF_SMC Ursula Braun

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=20150726.161530.2192841818929026804.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=ubraun@linux.vnet.ibm.com \
    --cc=ursula.braun@de.ibm.com \
    --cc=utz.bacher@de.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.