On 04/20/2018 08:19 AM, Jonathan Corbet wrote: > On Thu, 19 Apr 2018 18:01:32 -0700 > Eric Dumazet <eric.duma...@gmail.com> 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... >
Hi Jonathan > 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. Well, the thing is that most of our use cases wont reuse same mmap() area. RPC layer will provide all RPC with their associated pages to RPC consumers. RPC consumers will decide to keep these pages or consume them. So having to mmap() + another syscall to consume XXX bytes from receive queue is not going to save cpu cycles :/ Having the ability to call mmap() multiple times for the same TCP payload is not going to be of any use in real applications. This is why I only support 'offset 0' for the last mmap() parameter. > > - I would expect it to be a tiny bit faster, since you wouldn't be doing > the VMA setup and teardown each time. Maybe for the degenerated case we can reuse the same region over and over.
