> -----Original Message----- > From: J. Bruce Fields [mailto:bfields@xxxxxxxxxxxx] > Sent: Friday, January 25, 2013 4:35 PM > To: Myklebust, Trond > Cc: Ben Myers; Olga Kornievskaia; linux-nfs@xxxxxxxxxxxxxxx; Jim Rees > Subject: Re: sunrpc: socket buffer size tuneable > > On Fri, Jan 25, 2013 at 09:29:09PM +0000, Myklebust, Trond wrote: > > > -----Original Message----- > > > From: J. Bruce Fields [mailto:bfields@xxxxxxxxxxxx] > > > Sent: Friday, January 25, 2013 4:21 PM > > > To: Myklebust, Trond > > > Cc: Ben Myers; Olga Kornievskaia; linux-nfs@xxxxxxxxxxxxxxx; Jim > > > Rees > > > Subject: Re: sunrpc: socket buffer size tuneable > > > > > > On Fri, Jan 25, 2013 at 09:12:55PM +0000, Myklebust, Trond wrote: > > > > > > Why is it not sufficient to clamp the TCP values of 'snd' and > > > > 'rcv' using > > > sysctl_tcp_wmem/sysctl_tcp_rmem? > > > > ...and clamp the UDP values using > > > sysctl_[wr]mem_min/sysctl_[wr]mem_max?. > > > > > > Yeah, I was just looking at that--so, Ben, something like: > > > > > > echo "1048576 1048576 4194304" >/proc/sys/net/ipv4/tcp_wmem > > > > > > But I'm unclear on some of the details: do we need to set the > > > minimum or only the default? And does it need any more allowance > > > for protocol overhead? > > > > I meant adding a check either to svc_sock_setbufsize or to the 2 call-sites > that enforces the above limits. > > I lost you. > > It's not svc_sock_setbufsize that's setting too-small values, if that's what you > mean. > I understood that the problem was svc_udp_recvfrom() and svc_setup_socket() were using negative values in the calls to svc_sock_setbufsize(). Looking again at svc_setup_socket(), I don't see how that could do so, but svc_udp_recvfrom() definitely has potential to cause damage. The TCP layer should be taking care to always clamp the send/receive buffer sizes in tcp_new_space(),tcp_clamp_window(), etc... Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html