On Tue, 2010-08-31 at 18:26 -0700, Robert Love wrote: 
> On Wed, 2010-08-25 at 01:31 +0000, Bhanu Gollapudi wrote:
> > On systems with with higher nr_cpu_ids, per cpu exchange pool will
> > have very limited exchange resources. This can cause certain
> > operations such as discovery to fail even with finite amount
> > of retires. This problem is handled by dividing the entire
> 
> Hi Bhanu,
> 
>    Can you tell me a bit more about your scenario and how many CPUs
> you're dealing with? Is it an offload EM or non-offload EM that's
> running out of resources?

Hi Robert, 

I described the scenario in one of the earlier emails
http://www.mail-archive.com/[email protected]/msg07738.html

It is not an offload EM, and nr_cpu_ids in that system is 32, which
leaves only 128 xids per cpu pool.

> 
>       The (non-offload) EM starts with 4k XIDs. It must be an extreme case if
> it is running out of per-CPU XIDs. Especially if you're failing
> discovery, when there shouldn't be that many exchanges in use.

Please note that this is an extreme case, where there were 255 NPIV
ports and the issue was triggered when a switch port
shutdown/no-shutdown is performed. (There is another open issue in
disc_stop which tries to cancel itself, described in the email)

> 
> > exchange pool into two, one half to be used for cpu pool, and the
> > other half to be used as common pool. If the exchange resource
> > is not available in per cpu pool, the exchange resouce will
> > be obtained from the common pool.
> 
> I'm not sure the offload EM would want this common pool since the OEM
> may have a much smaller set of XIDs.

Doesnt the offload EM run into similar issues?

> 
> Thanks, //Rob
> 
> 




_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel

Reply via email to