Re: ixgbe and fast interrupts

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