All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Vasu Dev <vasu.dev@linux.intel.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Robert Love <robert.w.love@intel.com>,
	james.bottomley@hansenpartnership.com,
	linux-scsi@vger.kernel.org, jgarzik@redhat.com,
	davem@davemloft.net, james.smart@emulex.com,
	michaelc@cs.wisc.edu, jeykholt@cisco.com,
	jeffrey.t.kirsher@intel.com
Subject: Re: [PATCH 2/3] libfc: A modular Fibre Channel library
Date: Wed, 10 Dec 2008 20:42:52 +0100	[thread overview]
Message-ID: <20081210194252.GC25779@one.firstfloor.org> (raw)
In-Reply-To: <49400D94.5050301@linux.intel.com>

On Wed, Dec 10, 2008 at 10:42:28AM -0800, Vasu Dev wrote:
> 
> It had load balancing issue but now it is fixed, related latest 
> submitted code with its updated comment is:-
> 
> 	/*
> 	 * The incoming frame exchange id(oxid) is ANDed with num of online
> 	 * cpu bits to get cpu_idx and then this cpu_idx is used for 
> 	 selecting
> 	 * a per cpu kernel thread from fcoe_percpu. In case the cpu is
> 	 * offline or no kernel thread for derived cpu_idx then cpu_idx is
> 	 * initialize to first online cpu index.
> 	 */
> 	cpu_idx = oxid & (num_online_cpus() - 1);

First note that num_online_cpus() is not guaranteed to be a power of two,
- 1 is not guaranteed to give a suitable mask. So you might actually lose 
random bits. Also your load balancing scheme is unusual to say at least. 
e.g. when you're just talking to a single frame exchange you would always 
transfer data between CPUs instead of keeping it all on the CPU that 
processes the interrupt. Normally the rule of thumb is to use local
data as much as possible. Or when you distribute like this at least
stay in the same socket. But probably the scheme is too clever anyways.

-Andi
-- 
ak@linux.intel.com

  reply	other threads:[~2008-12-10 19:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-09 23:10 [PATCH 0/3] Open-FCoE Submission (round 2) Robert Love
2008-12-09 23:10 ` [PATCH 1/3] FC protocol definition header files Robert Love
2008-12-09 23:10 ` [PATCH 2/3] libfc: A modular Fibre Channel library Robert Love
2008-12-10  0:03   ` Andi Kleen
2008-12-10 18:42     ` Vasu Dev
2008-12-10 19:42       ` Andi Kleen [this message]
2008-12-12  1:55         ` Vasu Dev
2008-12-12  2:19           ` Joe Eykholt
2008-12-11  0:44     ` Chris Leech
2008-12-11  0:49     ` Chris Leech
2008-12-11 20:32     ` Zou, Yi
2008-12-11 23:33       ` Andi Kleen
2008-12-09 23:10 ` [PATCH 3/3] fcoe: Fibre Channel over Ethernet Robert Love
2009-02-05  2:24   ` Andrew Morton
2009-02-06 19:05     ` Robert Love
2009-02-06 19:13       ` Andrew Morton
2009-02-06 19:26         ` [PATCH] kernel-doc: preferred ending marker and examples Randy Dunlap
  -- strict thread matches above, loose matches on Subject: below --
2008-11-18 22:20 [PATCH 0/3] Open-FCoE Submission Robert Love
2008-11-18 22:21 ` [PATCH 2/3] libfc: A modular Fibre Channel library Robert Love
2008-11-24 10:13   ` Andi Kleen
2008-11-25 20:47     ` Love, Robert W
2008-12-02 23:36     ` Love, Robert W

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=20081210194252.GC25779@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=davem@davemloft.net \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=james.smart@emulex.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jeykholt@cisco.com \
    --cc=jgarzik@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    --cc=robert.w.love@intel.com \
    --cc=vasu.dev@linux.intel.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.