From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net-next] tcp: try to keep packet if SYN_RCV race is lost Date: Wed, 14 Feb 2018 14:22:33 -0500 (EST) Message-ID: <20180214.142233.692782705214933182.davem@davemloft.net> References: <1518531252.3715.178.camel@gmail.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=euc-kr Content-Transfer-Encoding: 8bit Cc: netdev@vger.kernel.org, soukjin.bae@samsung.com To: eric.dumazet@gmail.com Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:57592 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162787AbeBNTWf (ORCPT ); Wed, 14 Feb 2018 14:22:35 -0500 In-Reply-To: <1518531252.3715.178.camel@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Eric Dumazet Date: Tue, 13 Feb 2018 06:14:12 -0800 > From: Eric Dumazet > > 배석진 reported that in some situations, packets for a given 5-tuple > end up being processed by different CPUS. > > This involves RPS, and fragmentation. > > 배석진 is seeing packet drops when a SYN_RECV request socket is > moved into ESTABLISH state. Other states are protected by socket lock. > > This is caused by a CPU losing the race, and simply not caring enough. > > Since this seems to occur frequently, we can do better and perform > a second lookup. > > Note that all needed memory barriers are already in the existing code, > thanks to the spin_lock()/spin_unlock() pair in inet_ehash_insert() > and reqsk_put(). The second lookup must find the new socket, > unless it has already been accepted and closed by another cpu. > > Note that the fragmentation could be avoided in the first place by > use of a correct TCP MSS option in the SYN{ACK} packet, but this > does not mean we can not be more robust. > > Many thanks to 배석진 for a very detailed analysis. > > Reported-by: 배석진 > Signed-off-by: Eric Dumazet Applied, thanks Eric.