netdev - Re: [PATCH net-next 1/3] tcp: introduce TCP experimental option for SMC

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]

Message-ID: <1436277433.18112.7.camel@BR9GV9YG.de.ibm.com>
Date:	Tue, 07 Jul 2015 15:57:13 +0200
From:	Ursula Braun <ubraun@...ux.vnet.ibm.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	davem@...emloft.net, utz.bacher@...ibm.com, netdev@...r.kernel.org,
	linux-s390@...r.kernel.org, ursula.braun@...ibm.com
Subject: Re: [PATCH net-next 1/3] tcp: introduce TCP experimental option for
 SMC

Eric,

understood, would it be acceptable if the SMC-specific hooks in the
TCP-code are enclosed with "#ifdef CONFIG_SMC ... #endif"?

Regards, Ursula

On Mon, 2015-07-06 at 18:08 +0200, Eric Dumazet wrote:
> On Mon, 2015-07-06 at 17:11 +0200, Ursula Braun wrote:
> > From: Ursula Braun <ursula.braun@...ibm.com>
> > 
> > The SMC-R protocol defines dynamic discovery of peers. This is done by
> > implementing experimental TCP options as defined in RFC6994. The TCP code
> > needs to be extended to support RFC6994.
> > 
> > Setting the TCP experimental option for SMC-R [2] will be triggered from
> > kernel exploiters like the new SMC-R socket family by setting a new
> > flag "syn_smc" on struct tcp_sock of the connecting and the listening
> > socket. If the client peer is SMC-R capable, flag syn_smc is kept on the
> > connecting socket after the 3-way TCP handshake, otherwise it is reset.
> > If the server peer is SMC-R capable, the new connected TCP socket has
> > the new flag set, otherwise not.
> > 
> > Code snippet client:
> >   tcp_sk(sock->sk)->syn_smc = 1;
> >   rc = kernel_connect(sock, addr, alen, flags);
> >   if (tcp_sk(sock->sk)->syn_smc) {
> >           /* switch to smc for this connection */
> > 
> > Code snippet server:
> >   tcp_sk(sock->sk)->syn_smc = 1;
> >   rc = kernel_listen(sock, backlog);
> >   rc = kernel_accept(sock, &newsock, 0);
> >   if (tcp_sk(newsock->sk)->syn_smc) {
> >           /* switch to smc for this connection */
> > 
> > References:
> > [1] Shared Use of TCP Experimental Options RFC 6994:
> >     https://tools.ietf.org/rfc/rfc6994.txt
> > [2] IANA ExID SMCR:
> >     http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-exids
> > 
> > This patch has already been posted in June 2013, but Dave Miller has
> > postponed applying till the user of the new flags, ie. the entire SMC-R
> > protocol stack is implemented.
> > 
> > Signed-off-by: Ursula Braun <ubraun@...ux.vnet.ibm.com>
> 
> 
> >  struct tcp_out_options {
> >  	u16 options;		/* bit field of OPTION_* */
> > @@ -544,6 +545,14 @@ static void tcp_options_write(__be32 *ptr, struct tcp_sock *tp,
> >  		}
> >  		ptr += (len + 3) >> 2;
> >  	}
> > +
> > +	if (unlikely(OPTION_SMC & options)) {
> > +		*ptr++ = htonl((TCPOPT_NOP  << 24) |
> > +			       (TCPOPT_NOP  << 16) |
> > +			       (TCPOPT_EXP <<  8) |
> > +			       (TCPOLEN_EXP_SMC_BASE));
> > +		*ptr++ = htonl(TCPOPT_SMC_MAGIC);
> > +	}
> >  }
> 
> 
> I am concerned about adding an additional conditional branch in TCP
> write fast path, on all hosts, while SMC seems to be available only for
> some hardware class.
> 
> 
> 
> 


--
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