[PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive
syzbot reported a lockdep issue caused by tcp mmap() support. I implemented Andy Lutomirski nice suggestions to resolve the issue and increase scalability as well. First patch is adding a new setsockopt() operation and changes mmap() behavior. Second patch changes tcp_mmap reference program. v2: Added a missing page align of zc->length in tcp_zerocopy_receive() Properly clear zc->recv_skip_hint in case user request was completed. Eric Dumazet (2): tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE include/uapi/linux/tcp.h | 8 ++ net/ipv4/tcp.c | 189 + tools/testing/selftests/net/tcp_mmap.c | 63 + 3 files changed, 142 insertions(+), 118 deletions(-) -- 2.17.0.441.gb46fe60e1d-goog
Re: [PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive
On Wed, Apr 25, 2018 at 5:43 PM, Eric Dumazet wrote: > syzbot reported a lockdep issue caused by tcp mmap() support. > > I implemented Andy Lutomirski nice suggestions to resolve the > issue and increase scalability as well. > > First patch is adding a new setsockopt() operation and changes mmap() > behavior. > > Second patch changes tcp_mmap reference program. > > v2: > Added a missing page align of zc->length in tcp_zerocopy_receive() > Properly clear zc->recv_skip_hint in case user request was completed. Acked-by: Soheil Hassas Yeganeh Thank you Eric for the nice redesign! > Eric Dumazet (2): > tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive > selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE > > include/uapi/linux/tcp.h | 8 ++ > net/ipv4/tcp.c | 189 + > tools/testing/selftests/net/tcp_mmap.c | 63 + > 3 files changed, 142 insertions(+), 118 deletions(-) > > -- > 2.17.0.441.gb46fe60e1d-goog >
Re: [PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive
On 04/25/2018 06:20 PM, Soheil Hassas Yeganeh wrote: > > Acked-by: Soheil Hassas Yeganeh > > Thanks Soheil for reviewing. I have changed setsockopt() to getsockopt() so chose to not carry your Acked-by Please add it back if you agree, thanks !
Re: [PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive
At the risk of further muddying the waters, there's another minor tweak that could improve performance on certain workloads. Currently you mmap() a range for a given socket and then getsockopt() to receive. If you made it so you could mmap() something once for any number of sockets (by mmapping /dev/misc/tcp_zero_receive or whatever), then the performance of the getsockopt() bit would be identical, but you could release the mapping for many sockets at once with only a single flush. For some use cases, this could be a big win. You could also add this later easily enough, too.
Re: [PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive
On 04/26/2018 02:16 PM, Andy Lutomirski wrote: > At the risk of further muddying the waters, there's another minor tweak > that could improve performance on certain workloads. Currently you mmap() > a range for a given socket and then getsockopt() to receive. If you made > it so you could mmap() something once for any number of sockets (by > mmapping /dev/misc/tcp_zero_receive or whatever), then the performance of > the getsockopt() bit would be identical, but you could release the mapping > for many sockets at once with only a single flush. For some use cases, > this could be a big win. > > You could also add this later easily enough, too. > I believe I implemented what you just described. The getsockopt() call checks that the VMA was created by a mmap() to one TCP socket. It does not check that the vma was created by mmap() on the same socket, because we do not need this extra check really. So you presumably could use mmap() to grab 1GB of virtual space, then split it as you wish for different sockets. Thanks.
