Date: Fri, 18 Nov 2011 18:54:33 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: John Baldwin <jhb@freebsd.org> Cc: Matteo Landi <matteo@matteolandi.net>, freebsd-current@freebsd.org Subject: Re: ixgbe and fast interrupts Message-ID: <20111118175433.GA13459@onelab2.iet.unipi.it> In-Reply-To: <201111181220.04846.jhb@freebsd.org> References: <CALJ8J_HPZewO12uanb=kctQYwepMssr63E0DQh9CqV6PGaC=JA@mail.gmail.com> <201111180800.06593.jhb@freebsd.org> <20111118170615.GA9762@onelab2.iet.unipi.it> <201111181220.04846.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 18, 2011 at 12:20:04PM -0500, John Baldwin wrote: > On Friday, November 18, 2011 12:06:15 pm Luigi Rizzo wrote: ... > > A bit more context: Matteo is looking at the latency of RPCs across > > the network involving userspace processes, and possibly using the > > netmap API. As we understand it: > > > > if you are not using a filter, the interrupt calls a "predefined" > > filter (kern_intr.c::intr_event_schedule_thread() ? ) which wakes > > up the handler thread which in turn wakes up the user process. This > > means two scheduler invocations on each side. > > Yes, but if you use a filter you still have to do that as your filter would > just be queueing a task to on a taskqueue which would then do the actual > selwakeup() from a taskqueue thread. Filters are typically used to avoid > masking the interrupt in the PIC, or to limit the handlers executed on a > shared interrupt. > > > In the case of netmap, all the handler needs to do is a selwakeup() > > of the user thread blocked on the file descriptor, so if this > > can be done in the filter we can save an extra step through the > > scheduler. > > You can't call selwakeup() from a filter, it is not safe since it uses > mutexes, etc. There are only a few things you can do from a filter. > You could do a plain wakeup() if you let userland use a custom ioctl to > block on the filter, but not selwakeup(). ok, this is good to know - i wasn't sure if selwakeup() could block (and i am a bit unclear why). Will look at the selrecord/selwakeup pair, thanks for the suggestion. One more thing (i am mentioning it here for archival purposes, as i keep forgetting to test it). Is entropy harvesting expensive ? I see it is on by default > sysctl -a | grep rando kern.randompid: 0 kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0 ... and there seems to be a call to random_harvest() in the default filter that wakes up the threaded handler. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111118175433.GA13459>