Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp479158pxb; Tue, 14 Sep 2021 01:49:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1beM82QPbLri6YIrzCUf8Ci0Dk/244+TlXDDrsvda5HT+WOkWHx5EyG8O9MTNjoNwA/cL X-Received: by 2002:a17:906:1707:: with SMTP id c7mr16873378eje.377.1631609383639; Tue, 14 Sep 2021 01:49:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631609383; cv=none; d=google.com; s=arc-20160816; b=ra9BnV1aiQOPfAiggWR9t42O/VB9cVY5bcGPGDlo72fL047HSX6NocUvA2kCfZfuPO //bD66T7aw8YCDWOtCh1sPQdDP+77QyCgBt73A+nH/YSYImb1u8P2I5Jb/P2xSEVSWI/ dDgows/DQ1aL25PYmRIxk6zoEch4j7nIOqJOcTYh+Fhyu0C81b1wrmw+AwiOYfuW2Hgd YgvfkNXIaKlMYQb3oDrS89crKojkPhac5xQSuHOaKCQApwUapxlatbAEzf5hgDEkNIEu FAWWwE7mPhyEkSz0Qdhp67zGOaCbsOSG0Z+dUZtHZ0drijtKsQ9owjsKttiKbA5/4x2u yTww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=kZkMH63iTQ1WWrdV9xSbbANfuGbUt17bCT5Dl2F/Da0=; b=HRpGcnIIGYzRoefquFDNUYNCmrxVWkUBa0iBiU38i3dGTUGSR/oKkN0DSxz6yqm3rW Qw4yJpLTYDk1kkOb+7Zt+t4hF8oeWUuq7ptbVR1S8CZOyeD2kQX0x8TEds4dkpp/IyEb XijD6gdfEKL7aRxd10s1uqrIm5tGPI0FkR5xz1qA8i1/AVum4AnILDp7qthVTUzyjbvg MV65HtAn/YPM8p+F2seWozsLdwL7wocknP81zTGj9wIheDhI3wqDMTPWSXfxXa+xkfO+ u+oivXXQCKpm3jcRpetB6UVXMPXvctQjXGeHMzCrugWtmrw8NSqT4MgPWzwFkEQbiEMu Habw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=XWISWXbc; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=MJG30rqD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c14si41963edx.189.2021.09.14.01.49.19; Tue, 14 Sep 2021 01:49:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=XWISWXbc; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=MJG30rqD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230330AbhINIrd (ORCPT + 99 others); Tue, 14 Sep 2021 04:47:33 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:55408 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229648AbhINIrc (ORCPT ); Tue, 14 Sep 2021 04:47:32 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 3B18A21EA2; Tue, 14 Sep 2021 08:46:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1631609174; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kZkMH63iTQ1WWrdV9xSbbANfuGbUt17bCT5Dl2F/Da0=; b=XWISWXbcR3YdaeFQmM4w9+ukkxf4jSK2eqmQDo5iZ73XBLhF4jEDM8+2E0VxGtr5eFJxiC nmb3T0gwe1ndT5H4JdLDKKBI4kjUyc4fjA7c0T2KqDcf4D22+99oItZYY+wjvqFoIvzlqP K00ktKQrEH5F+uB2Tz7EXYr8uqK/J68= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1631609174; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kZkMH63iTQ1WWrdV9xSbbANfuGbUt17bCT5Dl2F/Da0=; b=MJG30rqDnzxe65gQiiRdUUjTdYTTjoLnMy+u/ZtPzlpYnjvOOgqHQqAJZ29ngBM7p6RPor ImJkDb/zx1w6yLBA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 29AD313D3F; Tue, 14 Sep 2021 08:46:14 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id KUIwClZhQGGpLAAAMHmgww (envelope-from ); Tue, 14 Sep 2021 08:46:14 +0000 Date: Tue, 14 Sep 2021 10:46:13 +0200 From: Daniel Wagner To: Christoph Hellwig Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [RFC v1] nvme-tcp: enable linger socket option on shutdown Message-ID: <20210914084613.75qykjxweh66mdpx@carbon> References: <20210903121757.140357-1-dwagner@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 06, 2021 at 08:58:20AM +0100, Christoph Hellwig wrote: > On Fri, Sep 03, 2021 at 02:17:57PM +0200, Daniel Wagner wrote: > > When the no linger is set, the networking stack sends FIN followed by > > RST immediately when shutting down the socket. By enabling linger when > > shutting down we have a proper shutdown sequence on the wire. > > > > Signed-off-by: Daniel Wagner > > --- > > The current shutdown sequence on the wire is a bit harsh and > > doesn't let the remote host to react. I suppose we should > > introduce a short (how long?) linger pause when shutting down > > the connection. Thoughs? > > Why? I'm not really a TCP expert, but why is this different from > say iSCSI or NBD? I am also no TCP expert. Adding netdev to Cc. During testing the nvme-tcp subsystem by one of our partners we observed this. Maybe this is perfectly fine. Just as I said it looks a bit weird that a proper shutdown of the connection a RST is send out right after the FIN. No idea how iSCSI or NBD handles this. I'll check.