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 > > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
