Date: Mon, 11 Feb 2002 11:26:45 -0800 From: Alfred Perlstein <bright@mu.org> To: Mike Silbersack <silby@silby.com> Cc: Tariq Rashid <tariq@inty.net>, freebsd-net@FreeBSD.ORG Subject: Re: squeeze more performance out of natd? Message-ID: <20020211112645.F63886@elvis.mu.org> In-Reply-To: <20020211130512.S84750-100000@patrocles.silby.com>; from silby@silby.com on Mon, Feb 11, 2002 at 01:08:07PM %2B0000 References: <MPENKFCCIIDAJKJJOLBHOEAHCIAA.tariq@inty.net> <20020211130512.S84750-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Mike Silbersack <silby@silby.com> [020211 11:05] wrote: > > On Mon, 11 Feb 2002, Tariq Rashid wrote: > > > some tests seems to show that natd's cpu load goes up because we have a > > large file descriptor set for select() - this is more of a problem than the > > kernelspace/userland packet traversal. the traffic its handling is something > > like 1500 low traffic tcp connections to a single server port. > > > > from doing some rtfm-ing i see that select() is not very scalable - not > > good for large fd sets and not good if they are nearly alwats ready for > > reading. > > The best way to improve performance would probably be to rewrite natd to > use kqueue instead of select. I'm not sure how difficult this would be, > you might wish to talk to jlemon if you have any questions on the best way > to tackle the project. That's what I thought initially, however the problem is that each packet requires at least a select(2) then recvfrom(2) and then possibly a sendto(2). The select(2) loop is particulary niave as the dispatched functions will only pull one packet from the socket instead of looping until the outstanding data is removed. Yes, another way would be to loop doing recvfrom's until EAGAIN is returned, I suspect this may give at least a 2 fold increase in performance and is trivial to accomplish. another would be to figure out a way to pull multiple packets via some recvfrom-like call that can return multiple sockaddrs, this would probably also give a very nice performance improvement. another way to improve it slightly would be to use kevent, failing that, there's always moving it into the kernel where the perf would most likely get better by several orders of magnitude by avoiding copies and userspace/kernel context switching. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020211112645.F63886>