From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by mail19.linbit.com (LINBIT Mail Daemon) with ESMTP id 3135F4203D6 for ; Thu, 21 May 2020 11:08:14 +0200 (CEST) Date: Thu, 21 May 2020 11:08:12 +0200 From: 'Christoph Hellwig' To: David Laight Message-ID: <20200521090812.GA8330@lst.de> References: <20200520195509.2215098-1-hch@lst.de> <20200520195509.2215098-32-hch@lst.de> <20200520231001.GU2491@localhost.localdomain> <20200520.162355.2212209708127373208.davem@davemloft.net> <20200520233913.GV2491@localhost.localdomain> <20200521083442.GA7771@lst.de> <0a6839ab0ba04fcf9b9c92784c9564aa@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a6839ab0ba04fcf9b9c92784c9564aa@AcuMS.aculab.com> Cc: Marcelo Ricardo Leitner , "edumazet@google.com" , "linux-nvme@lists.infradead.org" , "linux-sctp@vger.kernel.org" , "target-devel@vger.kernel.org" , "linux-afs@lists.infradead.org" , "drbd-dev@lists.linbit.com" , "linux-cifs@vger.kernel.org" , "rds-devel@oss.oracle.com" , "linux-rdma@vger.kernel.org" , 'Christoph Hellwig' , "cluster-devel@redhat.com" , "kuznet@ms2.inr.ac.ru" , "kuba@kernel.org" , "ceph-devel@vger.kernel.org" , "linux-nfs@vger.kernel.org" , "nhorman@tuxdriver.com" , "yoshfuji@linux-ipv6.org" , "netdev@vger.kernel.org" , "vyasevich@gmail.com" , "linux-kernel@vger.kernel.org" , "jmaloy@redhat.com" , "ying.xue@windriver.com" , David Miller , "ocfs2-devel@oss.oracle.com" Subject: Re: [Drbd-dev] [PATCH 31/33] sctp: add sctp_sock_set_nodelay List-Id: "*Coordination* of development, patches, contributions -- *Questions* \(even to developers\) go to drbd-user, please." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, May 21, 2020 at 09:06:19AM +0000, David Laight wrote: > > > The comment still applies, though. (re the duplication) > > > > Where do you see duplication? > > The whole thing just doesn't scale. > > As soon as you get to the slightly more complex requests > like SCTP_INITMSG (which should probably be called to > set the required number of data streams) you've either > got replicated code or nested wrappers. None of that is relevant to setting the nodelay option. If you actually read through the series you'd say that whenever there was non-trivial logic it is shared with getopt. However sharing just for purpose of sharing doesn't make sense, so where the kernel API ended up just setting a flag after taking the sock lock I did not opt for it.