From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Xu, Dongxiao" <dongxiao.xu@intel.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Steven Smith <steven.smith@citrix.com>
Subject: Re: [Pv-ops][PATCH 3/4 v2] Netback: Multiple tasklets support
Date: Mon, 3 May 2010 12:06:44 -0400 [thread overview]
Message-ID: <20100503160644.GE31299@phenom.dumpdata.com> (raw)
In-Reply-To: <D5AB6E638E5A3E4B8F4406B113A5A19A1D94B18A@shsmsx501.ccr.corp.intel.com>
On Thu, Apr 29, 2010 at 10:28:50PM +0800, Xu, Dongxiao wrote:
> Netback: Multiple tasklets support.
>
> Now netback uses one pair of tasklets for Tx/Rx data transaction.
> Netback tasklet could only run at one CPU at a time, and it is
> used to serve all the netfronts. Therefore it has become a
> performance bottle neck. This patch is to use multiple tasklet
> pairs to replace the current single pair in dom0.
>
> Assuming that Dom0 has CPUNR VCPUs, we define CPUNR kinds of
> tasklets pair (CPUNR for Tx, and CPUNR for Rx). Each pare of
^^^ -> pair
> tasklets serve specific group of netfronts. Also for those global
> and static variables, we duplicated them for each group in
> order to avoid the spinlock.
scripts/checkpatch.pl --strict
~/0003-Netback-Multiple-tasklets-support.patch
CHECK: spinlock_t definition without comment
#42: FILE: drivers/xen/netback/common.h:292:
+ spinlock_t group_operation_lock;
total: 0 errors, 0 warnings, 1 checks, 626 lines checked
/home/konrad/0003-Netback-Multiple-tasklets-support.patch has style
problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
>
> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
+static void netbk_add_netif(struct xen_netbk *netbk, int group_nr,
+ struct xen_netif *netif)
+{
+ int i;
+ int min_netfront_count;
+ int min_group = 0;
+ spin_lock(&netbk->group_operation_lock);
+ min_netfront_count = netbk[0].netfront_count;
+ for (i = 0; i < group_nr; i++) {
+ if (netbk[i].netfront_count < min_netfront_count) {
+ min_group = i;
+ min_netfront_count = netbk[i].netfront_count;
Should you have a 'break' here? I am not sure if it makes sense to go
through all of the tasklets to set the min_group and min_netfrount_count to the last
one?
+ }
+ }
+
+ netif->group = min_group;
+ netbk[netif->group].netfront_count++;
+ spin_unlock(&netbk->group_operation_lock);
+}
+
+static void netbk_remove_netif(struct xen_netbk *netbk, struct xen_netif *netif)
+{
+ spin_lock(&netbk->group_operation_lock);
+ netbk[netif->group].netfront_count--;
+ spin_unlock(&netbk->group_operation_lock);
+}
+
static void __netif_up(struct xen_netif *netif)
{
enable_irq(netif->irq);
@@ -333,6 +360,8 @@ int netif_map(struct xen_netif *netif, unsigned long tx_ring_ref,
if (netif->rx_comms_area == NULL)
goto err_rx;
+ netbk_add_netif(xen_netbk, xen_netbk_group_nr, netif);
+
Say you have 7 VIFs and only 4 VCPUs, are these netfront_count values
correct?
netbk[0].netfront_count == 1; /* vif0 added */
netbk[3].netfront_count == 1; /* vif1 added */
netbk[2].netfront_count == 1; /* vif2 added */
netbk[1].netfront_count == 1; /* vif3 added */
netbk[0].netfront_count == 2; /* vif4 added */
netbk[3].netfront_count == 2; /* vif5 added */
netbk[2].netfront_count == 2; /* vif6 added */
I just want to make sure I understand the allocation algorithm
correctly.
next prev parent reply other threads:[~2010-05-03 16:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-29 14:28 [Pv-ops][PATCH 3/4 v2] Netback: Multiple tasklets support Xu, Dongxiao
2010-05-03 16:06 ` Konrad Rzeszutek Wilk [this message]
2010-05-04 0:55 ` Xu, Dongxiao
2010-05-04 13:23 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100503160644.GE31299@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=dongxiao.xu@intel.com \
--cc=jeremy@goop.org \
--cc=steven.smith@citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.