auto tuning tcp

[Michael Tuexen]

On Nov 13, 2012, at 1:43 PM, Andre Oppermann wrote:

> On 13.11.2012 09:41, Alfred Perlstein wrote:
>> On 11/13/12 12:25 AM, Andre Oppermann wrote:
>>> On 13.11.2012 09:18, Alfred Perlstein wrote:
>>>> On 11/13/12 12:06 AM, Andre Oppermann wrote:
>>>>> On 13.11.2012 07:45, Alfred Perlstein wrote:
>>>>>> If you are concerned about the space/time tradeoff I'm pretty happy with making it 1/2, 1/4th,
>>>>>> 1/8th
>>>>>> the size of maxsockets.  (smaller?)
>>>>>> 
>>>>>> Would that work better?
>>>>> 
>>>>> I'd go for 1/8 or even 1/16 with a lower bound of 512.  More than
>>>>> that is excessive.
>>>> 
>>>> I'm OK with 1/8.  All I'm really going for is trying to make it somewhat better than 512 when
>>>> un-tuned.
>>> >
>>>>> PS: Please note that my patch for mbuf and maxfiles tuning is not yet
>>>>> in HEAD, it's still sitting in my tcp_workqueue branch.  I still have
>>>>> to search for derived values that may get totally out of whack with
>>>>> the new scaling scheme.
>>>>> 
>>>> This is cool!  Thank you for the feedback.
>>>> 
>>>> Would you like me to put this on a user branch somewhere for you to merge into your perf branch?
>>> 
>>> I can put it into my branch and also merge it to HEAD with
>>> a "Submitted by: alfred" line.
>>> 
>> Thank you, that works.  Note: it's not even compile tested at this point.
>> 
>> I should be able to do so tomorrow.
>> 
>> Are there other hashes to look at?  I noticed a few more:
>> 
>> UDBHASHSIZE
> 
> Even busy UDP servers have only a small number of sockets open.
> 
>> netinet/tcp_hostcache.c:#define TCP_HOSTCACHE_HASHSIZE          512
> 
> This is per host, not per connection or socket.  So it should by fine
> and scales independently.
> 
>> netinet/sctp_constants.h:#define SCTP_TCBHASHSIZE 1024
>> netinet/sctp_constants.h:#define SCTP_PCBHASHSIZE 256
> 
> Michael has look at that.
I can take a look... I also wanted to make it configurable...

Best regards
Michael
> 
>> netinet/tcp_syncache.c:#define TCP_SYNCACHE_HASHSIZE            512
> 
> Again this is not per connection or socket.  It depends on the number
> of concurrent SYN's waiting on SYN/ACK-ACK for a listen socket.  This
> should be fine and it has overflow protection.  If a SYN entry is lost
> it reverts to syncookies.
> 
>> Any of these look like good targets?  I think most could be looked at. I've only glanced.  I can
>> provide deltas.
> 
> -- 
> Andre
> 
>