* Re: [TCP]: rcvbuf lock when tcp_moderate_rcvbuf enabled
@ 2006-03-23 9:04 Dan Aloni
2006-03-23 15:58 ` John Heffner
0 siblings, 1 reply; 2+ messages in thread
From: Dan Aloni @ 2006-03-23 9:04 UTC (permalink / raw)
To: Linux Kernel List; +Cc: John Heffner, David S. Miller, dror
Hello,
Below, I've forwarded change from 2.6.16 which I think may causes
problems for applications that use setsockopt with SO_RCVBUF. We are
using an implementation of an iSCSI target and according to network
sniffs it seems that during data transfer the receive window
unjustifyingly shrinks to a very low size (180 bytes). I can guess
that the code below indirectly affects the receive window size, but
I'm not sure how it the logic works here, a clarification could be
helpful.
It's worth to mention that we have sysctl_tcp_moderate_rcvbuf=1, but
I don't think it should interfere with applications that request to
have a fixed receive buffer by the means of setsockopt(). I can also
tell by experiment that reverting the change below makes the problem
go away.
--- a97ed5416c28ee14ecab0ac4483c079a0c3e4c1d
+++ e9a54ae7d6903845598db14a8e1cba54026faf1b
@@ -456,7 +456,8 @@ void tcp_rcv_space_adjust(struct sock *s
tp->rcvq_space.space = space;
- if (sysctl_tcp_moderate_rcvbuf) {
+ if (sysctl_tcp_moderate_rcvbuf &&
+ !(sk->sk_userlocks & SOCK_RCVBUF_LOCK)) {
int new_clamp = space;
/* Receive space grows, normalize in order to
--
Dan Aloni
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net, dan@xiv.co.il
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [TCP]: rcvbuf lock when tcp_moderate_rcvbuf enabled
2006-03-23 9:04 [TCP]: rcvbuf lock when tcp_moderate_rcvbuf enabled Dan Aloni
@ 2006-03-23 15:58 ` John Heffner
0 siblings, 0 replies; 2+ messages in thread
From: John Heffner @ 2006-03-23 15:58 UTC (permalink / raw)
To: Dan Aloni; +Cc: Linux Kernel List, David S. Miller, dror
On Thursday 23 March 2006 04:04, Dan Aloni wrote:
> Hello,
>
> Below, I've forwarded change from 2.6.16 which I think may causes
> problems for applications that use setsockopt with SO_RCVBUF. We are
> using an implementation of an iSCSI target and according to network
> sniffs it seems that during data transfer the receive window
> unjustifyingly shrinks to a very low size (180 bytes). I can guess
> that the code below indirectly affects the receive window size, but
> I'm not sure how it the logic works here, a clarification could be
> helpful.
>
> It's worth to mention that we have sysctl_tcp_moderate_rcvbuf=1, but
> I don't think it should interfere with applications that request to
> have a fixed receive buffer by the means of setsockopt(). I can also
> tell by experiment that reverting the change below makes the problem
> go away.
It shouldn't, but it used to. That's exactly what this patch changes (making
tcp_moderate_rcvbuf *not* override the application's requested buffer size).
Is it possible the application isn't asking for enough buffer space, and that
the kernel was just automatically helping it before this patch went in?
-John
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-03-23 15:58 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-03-23 9:04 [TCP]: rcvbuf lock when tcp_moderate_rcvbuf enabled Dan Aloni
2006-03-23 15:58 ` John Heffner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome