netdev - Re: [PATCH] fix limited slow start bug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45DE1083.6040900@psc.edu>
Date:	Thu, 22 Feb 2007 16:52:03 -0500
From:	John Heffner <jheffner@....edu>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
CC:	David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] fix limited slow start bug

Ilpo Järvinen wrote:
> BTW, while looking this patch, I noticed that snd_cwnd_clamp is only u16 
> while snd_cwnd is u32, which seems rather strange since snd_cwnd is being 
> limited by the clamp value here and there?!?! And tcp_highspeed.c is 
> clearly assuming even more than this (but the problem is hidden as 
> snd_cwnd_clamp is feed back to the min_t and the used 32-bit constant 
> could be safely cut to 16-bits anyway):
> 
>   tp->snd_cwnd_clamp = min_t(u32, tp->snd_cwnd_clamp, 0xffffffff/128);
> 
> Has the type being changed somewhere in the past or why is this so?

It's been that way as long as I can remember.  It's always been a 
mystery to me as well.  I suspect the tcp_highspeed code is that way 
because this patch originally came out of the Web100-patched kernel, 
which at one point was using a 32 bit snd_cwnd_clamp IIRC.

I think it's not unreasonable to change clamp to 32 bits now, since with 
1500 byte packets, this corresponds to a max cwnd of ~94MB.  This is 
pretty big, but we are currently right at this limit with 10 GigE.

   -John
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html