net.inet.tcp.slowstart_flightsize in 8-STABLE

Lawrence Stewart lstewart at freebsd.org
Sat Nov 27 03:13:57 UTC 2010


On 11/13/10 00:18, Lawrence Stewart wrote:
> On 11/12/10 21:41, Kostik Belousov wrote:
>> On Fri, Nov 12, 2010 at 09:21:29PM +1100, Lawrence Stewart wrote:
>>> On 11/12/10 20:44, Lawrence Stewart wrote:
>>>> On 11/07/10 17:32, Lawrence Stewart wrote:
>>>>> On 11/03/10 09:30, Andre Oppermann wrote:
>>>>>> On 02.11.2010 01:11, Maxim Dounin wrote:
>>>>>>> Hello!
>>>>>>>
>>>>>>> On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote:
>>>>>>>
>>>>>>>> On 27.09.2010 10:12, Maxim Dounin wrote:
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote:
>>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>> Andre, could you please take a look at one more patch as well?
>>>>>>>>>>
>>>>>>>>>> Igor reported that it still sees 100ms delays with rfc3465 turned
>>>>>>>>>> on, and it turns out to be similar issue (setting cwnd to 1*MSS)
>>>>>>>>>> for hosts found in hostcache.
>>>>>>>>>>
>>>>>>>>>> The problem with setting cwnd from hostcache was already reported
>>>>>>>>>> here:
>>>>>>>>>>
>>>>>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92690
>>>>>>>>>> http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014780.html
>>>>>>>>>>
>>>>>>>>>> As using larger cwnd from hostcache may cause problems on
>>>>>>>>>> congested links (see second thread) I changed code to only use
>>>>>>>>>> cached cwnd as an upper bound for cwnd (instead of fixing current
>>>>>>>>>> code).  This is also in-line with what we do on connection
>>>>>>>>>> restarts.
>>>>>>>>>>
>>>>>>>>>> We may later consider re-adding usage of larger cwnd from
>>>>>>>>>> hostcache.  But I believe it should be done carefully and
>>>>>>>>>> probably behind sysctl, off by default.
>>>>>>>>>
>>>>>>>>> Ping.
>>>>>>>>
>>>>>>>> Thanks for the reminder.  I'll disable priming CWND from hostcache.
>>>>>>>
>>>>>>> Ping again.
>>>>>>>
>>>>>>> I would like to see the patch in question[1] committed and MFC'ed
>>>>>>> somewhere before 8.2.
>>>>>>>
>>>>>>> Andre, if you are just too busy to do it yourself - please say so,
>>>>>>> I'll ask somebody else to commit it.
>>>>>>
>>>>>> Thanks for the reminder.  After EuroBSDCon Developer Summit I was
>>>>>> busy with other work and most of my tcp work was stalled due to
>>>>>> review bandwidth issues.
>>>>>
>>>>> Sorry for the review bandwidth issues. I'm only just managing to keep my
>>>>> head above water at the moment and have had to reduce much of my FreeBSD
>>>>> work to a trickle.
>>>>>
>>>>>> Lawrence, could you please spare a few seconds and take a quick look
>>>>>> at the attached patch?
>>>>>
>>>>> The patch looks fine, please commit. I hope to give the hostcache some
>>>>> TLC at some point, but in the meantime it's fine to ignore cached cwnd.
>>>>
>>>> FYI Andre, this patch got rolled into r215166 because I had to move all
>>>> the code around which the patch was based on. Is that going to cause any
>>>> issues here? I should have checked prior to committing but completely
>>>> forgot I had pulled the patch into my dev tree before creating the mod
>>>> CC patch.
>>>
>>> Gah, I think I've answered my own question. MFCing the patch standalone
>>> in time for 8.2 as Maxim requested is not going to be possible. I think
>>> I'll have to back out r215166, commit your patch and then recommit the
>>> modular CC patch.
>>>
>>> Unless someone can think of a way that doesn't involve all the mucking
>>> about?
>> Well, if the change is indeed already in HEAD, you can do a direct commit
>> to stable/8 after proper MFC period, noting that this is a cherry-pick of
>> the part of corresponding revision.
> 
> hmm, not ideal but would get the job done. When I eventually MFC the
> modular CC patch everything will be back in sync mergeinfo wise as well.
> Would anyone object if I follow Kostik's suggestion and direct commit
> the TCP_METRICS_CWND patch to stable/8 in, say, a week's time? If I
> don't hear anything, I'll aim to do the commit next weekend.

FYI, committed to stable/8 as r215925 and stable/7 as r215926.

Cheers,
Lawrence


More information about the freebsd-net mailing list