From owner-svn-src-all@freebsd.org Thu Jun 2 14:28:32 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A6C4B65C47; Thu, 2 Jun 2016 14:28:32 +0000 (UTC) (envelope-from royger@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0055E1ECE; Thu, 2 Jun 2016 14:28:31 +0000 (UTC) (envelope-from royger@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id a136so233124845wme.0; Thu, 02 Jun 2016 07:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=A/DR2n+gGZMvyYYCVcM43XVw8UJrDhumScaoOGXHHKE=; b=PwxNTw6Zd9oyRK9Lbleq77JAFvpCAMYf0mvqzWSpLsB85p4pDoBiC/+OFGsbfOo58V ktzKIX1iTNY03PEqkFVAqwOa8UlusLv8vMd9tZHuj/BOz8O36q3j09Q6ORAL2nNoyg7z oJiqp/OxKa/zOJ0MmkLkrVld6rj+MZ4eIyab3ILX5cr3QKNWDPm9ZcmNNsatOKPWdvDn isZlErbFFhpBJ+3e7PCPuRBfwSQ+oZVFi7is6nkUXxG3/7b172AiqKW7eeBRg57eDKDB 2+A7BvPm2B3xtBSbT5DNbJO1CjbuV73mUbtwwtfwefco6T0CYR522fsoz4qH//V1Mihe tRow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=A/DR2n+gGZMvyYYCVcM43XVw8UJrDhumScaoOGXHHKE=; b=dnCzyZRxwr0arL7/ICNNM9L3SeJOfl+Zr4XEijlzwk/+fPHzWXEHvpDDC6Qw4MN12+ r6YG0YtjbKBrt8NV1WTATHv0gHBGtQWIpzuf59OebaDb64kqg7sp6nq8SjXhZgNTXYJu in2fDHIaasktbPUvIMcH0k9+DavZsYhvE+n5RAv/MYLYX52yjYtGbtGHoc5FHhvCEVaJ LjLfAw2tRLgH7EPskWmySlbCMwjF0Cl/LtUH5jAgqgvXSRoluYkF4asczNCFD0hTdDut 6Y89t2Wq+n/rp51YEAc9FM03WmVqP2K5R0b9Sx0Vzt8x8tVlEyjGTrbt7QoP1G5A3miq oUTg== X-Gm-Message-State: ALyK8tJj5yW4gufMhjGRY3Pk4gDCkb+CMATT2RnTBqFbNS+HvRbybm1ZrNzy8uJsqfBr1w== X-Received: by 10.194.110.137 with SMTP id ia9mr8894007wjb.107.1464877709737; Thu, 02 Jun 2016 07:28:29 -0700 (PDT) Received: from localhost (78.red-88-8-193.dynamicip.rima-tde.net. [88.8.193.78]) by smtp.gmail.com with ESMTPSA id lf7sm870707wjb.23.2016.06.02.07.28.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jun 2016 07:28:29 -0700 (PDT) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Date: Thu, 2 Jun 2016 16:28:24 +0200 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Hans Petter Selasky Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r301197 - head/sys/dev/xen/netfront Message-ID: <20160602142824.m6d24n2rx3i2kclt@mac> References: <201606021114.u52BEQqB047172@repo.freebsd.org> <2c81e44d-65de-10f0-8837-f23896855150@selasky.org> <20160602125422.gmdsueoeu5fiiec5@mac> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0-neo (2016-04-07) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 14:28:32 -0000 On Thu, Jun 02, 2016 at 03:01:03PM +0200, Hans Petter Selasky wrote: > On 06/02/16 14:54, Roger Pau Monné wrote: > > On Thu, Jun 02, 2016 at 01:19:56PM +0200, Hans Petter Selasky wrote: > > > On 06/02/16 13:14, Roger Pau Monné wrote: > > > > + callout_reset(&rxq->rx_refill, hz/10, xn_alloc_rx_buffers_callout, > > > > + rxq); > > > > > > Maybe use callout_reset_curcpu() to take advantage of callout's SMP > > > capabilities ? > > > > Yes, that's fine. But what's the benefit of it? I don't really care whether > > the callout is run on the current CPU or not. Is callout_reset_curcpu > > cheaper than callout_reset? > > > > Hi, > > It is maybe not cheaper, but it will distribute the load of the > xn_alloc_rx_buffers_callout() callback, to the current CPU calling > callout_reset_curcpu(). Else xn_alloc_rx_buffers_callout() will always be > called from callback thread zero. Thanks for the clarification. I did get the impression that callout_reset already distributed the callbacks across the number of available CPUs, maybe the man page should be expanded to explain this? I've committed the change as r301204. Roger.