From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 17:38:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62FF2106564A; Fri, 18 Nov 2011 17:38:54 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 213778FC16; Fri, 18 Nov 2011 17:38:53 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7A4AD7300A; Fri, 18 Nov 2011 18:54:33 +0100 (CET) Date: Fri, 18 Nov 2011 18:54:33 +0100 From: Luigi Rizzo To: John Baldwin Message-ID: <20111118175433.GA13459@onelab2.iet.unipi.it> References: <201111180800.06593.jhb@freebsd.org> <20111118170615.GA9762@onelab2.iet.unipi.it> <201111181220.04846.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111181220.04846.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Matteo Landi , freebsd-current@freebsd.org Subject: Re: ixgbe and fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 17:38:54 -0000 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