emulex FC driver on ppc64

emulex FC driver on ppc64

[Anton Blanchard]

Hi James,

I gave the sourceforge version of the emulex FC driver a spin on my
ppc64 box. Good news is it worked out of the box. I had a few
observations:

1. request_irq uses SA_INTERRUPT and SA_SHIRQ. I cant see mixing these
flags could be safe, and I doubt you need the SA_INTERRUPT in the first
place. Removing it also makes it easier to use timer tick profiling
because the interrupt routing runs with irqs on.

2. We now have dma_mapping_error so you can kill the NO_TCE, -1 hacks.

3. A number of the files need to be un dosified, they have carriage
returns in them.

4. lpfc_bad_scatterlist is pretty nasty stuff. If its going to be
impossible to get your firmware guys to fix this issue we could look at
working around it in the ppc64 IOMMU code. At least then we wont have to
walk each SG list, however theres every chance another architecture is
going to have the same problem.

5. #define MAX_ELX_BRDS 32
Do we need a hard limit? Can we just dynamically allocate the
structures? 32 is going to be way too small for some of our setups.
btw your MODULE_PARM code is scary :)

Anton

RE: emulex FC driver on ppc64

[Smart, James]

Anton,

Thanks for the feedback. I know we've only recently been working things out
on the PPC64.  Most of the things look pretty minor - we should be able to
get them in shortly. As for the MAX 32 - we've been looking at raising the
count as well, but prioritized it below all the other work items we've got
on the current list.

-- James S


> -----Original Message-----
> From: Anton Blanchard [mailto:anton@samba.org]
> Sent: Friday, April 09, 2004 10:21 PM
> To: Smart, James
> Cc: linux-scsi@vger.kernel.org
> Subject: emulex FC driver on ppc64
> 
> 
> 
> Hi James,
> 
> I gave the sourceforge version of the emulex FC driver a spin on my
> ppc64 box. Good news is it worked out of the box. I had a few
> observations:
> 
> 1. request_irq uses SA_INTERRUPT and SA_SHIRQ. I cant see mixing these
> flags could be safe, and I doubt you need the SA_INTERRUPT in 
> the first
> place. Removing it also makes it easier to use timer tick profiling
> because the interrupt routing runs with irqs on.
> 
> 2. We now have dma_mapping_error so you can kill the NO_TCE, -1 hacks.
> 
> 3. A number of the files need to be un dosified, they have carriage
> returns in them.
> 
> 4. lpfc_bad_scatterlist is pretty nasty stuff. If its going to be
> impossible to get your firmware guys to fix this issue we 
> could look at
> working around it in the ppc64 IOMMU code. At least then we 
> wont have to
> walk each SG list, however theres every chance another architecture is
> going to have the same problem.
> 
> 5. #define MAX_ELX_BRDS 32
> Do we need a hard limit? Can we just dynamically allocate the
> structures? 32 is going to be way too small for some of our setups.
> btw your MODULE_PARM code is scary :)
> 
> Anton
> 

Re: emulex FC driver on ppc64

[Jeff Garzik]

Smart, James wrote:
> Anton,
> 
> Thanks for the feedback. I know we've only recently been working things out
> on the PPC64.  Most of the things look pretty minor - we should be able to
> get them in shortly. As for the MAX 32 - we've been looking at raising the
> count as well, but prioritized it below all the other work items we've got
> on the current list.

I think you misunderstand Anton's suggestion, which I agree with:

If you dynamically allocate the structures, there is no need for any 
limit at all.  Most Linux drivers dynamically allocate these structures 
already, but a few (mostly simple) drivers do not.

In the future, dynamic allocation of these types of structures will be a 
requirement, in order to proper object lifetime (ref counting etc.) 
management.

	Jeff

RE: emulex FC driver on ppc64

[Smart, James]

There's no misunderstanding - I agree with you.  Just stating that the
reorganization and removal of the multi-os abstractions had to take place
first....

-- james

> -----Original Message-----
> From: Jeff Garzik [mailto:jgarzik@pobox.com]
> Sent: Saturday, April 10, 2004 8:45 PM
> To: Smart, James
> Cc: 'Anton Blanchard'; linux-scsi@vger.kernel.org
> Subject: Re: emulex FC driver on ppc64
> 
> 
> Smart, James wrote:
> > Anton,
> > 
> > Thanks for the feedback. I know we've only recently been 
> working things out
> > on the PPC64.  Most of the things look pretty minor - we 
> should be able to
> > get them in shortly. As for the MAX 32 - we've been looking 
> at raising the
> > count as well, but prioritized it below all the other work 
> items we've got
> > on the current list.
> 
> I think you misunderstand Anton's suggestion, which I agree with:
> 
> If you dynamically allocate the structures, there is no need for any 
> limit at all.  Most Linux drivers dynamically allocate these 
> structures 
> already, but a few (mostly simple) drivers do not.
> 
> In the future, dynamic allocation of these types of 
> structures will be a 
> requirement, in order to proper object lifetime (ref counting etc.) 
> management.
> 
> 	Jeff
> 
> 

Re: emulex FC driver on ppc64

[Jeff Garzik]

Smart, James wrote:
> There's no misunderstanding - I agree with you.  Just stating that the
> reorganization and removal of the multi-os abstractions had to take place
> first....

Cool, thanks.  I misunderstood your "we're looking at raising the count" 
comment to imply that you would simply increase the limit, rather than 
eliminate it.

Regards,

	Jeff