From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Corbet Subject: Re: [PATCH net-next 4/5] tcp: implement mmap() for zero copy receive Date: Fri, 20 Apr 2018 09:19:51 -0600 Message-ID: <20180420091951.713c0b95@lwn.net> References: <20180416173339.6310-1-edumazet@google.com> <20180416173339.6310-5-edumazet@google.com> <7a961ead-e77d-7334-3c29-399e071670fb@gmail.com> <1e7a78a6-27cd-9679-54d7-44d05484eda7@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Cc: Eric Dumazet , "David S . Miller" , netdev , Neal Cardwell , Yuchung Cheng , Soheil Hassas Yeganeh To: Eric Dumazet Return-path: Received: from ms.lwn.net ([45.79.88.28]:33990 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755382AbeDTPTw (ORCPT ); Fri, 20 Apr 2018 11:19:52 -0400 In-Reply-To: <1e7a78a6-27cd-9679-54d7-44d05484eda7@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 19 Apr 2018 18:01:32 -0700 Eric Dumazet wrote: > We can keep mmap() nice interface, granted we can add one hook like in following patch. > > David, do you think such patch would be acceptable by lkml and mm/fs maintainers ? > > Alternative would be implementing an ioctl() or getsockopt() operation, > but it seems less natural... So I have little standing here, but what the heck, not letting that bother me has earned me a living for the last 20 years or so...:) I think you should consider switching over to an interface where you mmap() the region once, and use ioctl() to move the data into that region, for a couple of reasons beyond the locking issues you've already found: - The "mmap() consumes data" semantics are a bit ... strange, IMO. That's not what mmap() normally does. People expect ioctl() to do magic things, instead. - I would expect it to be a tiny bit faster, since you wouldn't be doing the VMA setup and teardown each time. Thanks, jon