netdev - Re: [PATCH V3 net-next 0/5] net: implement SMC-R solution

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 31 Jul 2015 21:04:52 +0200
From:	Ursula Braun <ubraun@...ux.vnet.ibm.com>
To:	David Miller <davem@...emloft.net>
Cc:	utz.bacher@...ibm.com, netdev@...r.kernel.org,
	linux-s390@...r.kernel.org, schwidefsky@...ibm.com,
	heiko.carstens@...ibm.com, ursula.braun@...ibm.com
Subject: Re: [PATCH V3 net-next 0/5] net: implement SMC-R solution

On Sun, 2015-07-26 at 16:15 -0700, David Miller wrote:

> 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.
Correct, Dave: All the RDMA protocols do not benefit from packet-based
features of Linux networking. Which is why SMC-R starts with TCP to
maintain some of it. This allows for adhering to the TCP management
model, e.g. for addressing and capability to intercept connection
establishment. We did SMC-R for a good reason -- bringing value to the
mainframe datacenter environment, and potentially other setups, too; and
that includes performance benefits.
> 
> Furthermore the benchmarks are carefully choosen to exemplify the
> perfect environment for this feature to excell at.
Our benchmarks shown are by no means "some carefully chosen" selection.
Would you like to see some other benchmarks?
> 
> 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.
Since you are asking for a solution "100% in our own separate module
with our own can of worms", we have to give up the transparent detection
whether a communication peer can do SMC-R or not (this has been the
purpose of the rejected TCP hooks). Instead, we want just the new
self-contained SMC-R socket family added to the kernel. We will adapt
the code accordingly to get rid of TCP experimental options. Is it ok
for you, if we send the whole new code for /net/smc/ in one single patch
since all of it is required for doing the job, or prefer smaller chunks
(which, if half way applied, won't get real functionality)?

Kind regards, Ursula





--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html