RE: [ANNOUNCE][RELEASE]: megaraid unified driver version 2.20.0.B 1

RE: [ANNOUNCE][RELEASE]: megaraid unified driver version 2.20.0.B 1

[Mukker, Atul]

> kdep.h:
>  - mraid_scsi_host_alloc/mraid_scsi_host_dealloc should go away, just
>    define scsi_host_alloc/scsi_host_put wrappers for 2.4.
>  - mraid_scsi_set_pdev should go away, it's not needed in 2.6 at all
>    because scsi_add_host does all the work and for 2.4 just use
>    scsi_set_pci_device directly.
>  - all the SCP2FOO defines should go away, the 2.6 variants 
> work for 2.4
>    aswell
>  - mraid_set_host_lock should go, just use scsi_assign_lock and define
>    it for 2.4.
All of these taken and will be incorporated in B3, but not in B2 going out
today

> 
> megaraid_clib.c:
>   - why do you need the scb pool managment code at all?  You 
> can dynamically
>     allocate scbs in ->queuecommand
Will do. Please see the follow up question below

>   - can you explain the need for all the mraid_pci_blk_pool?  
> I.e. why the
>     generic dma pool routines don't work for megaraid
We did not want to use pci_alloc_consistent because it would give one page
even if we need 16 bytes (and we need a lot of these). Also, the
pci_poo_create and pci_pool_alloc would fail on some setups - maybe because
the driver requires lots of small chunks of DMAable buffers. So we decided
to write wrapper functions over pci_alloc_consistent..

> 
> all files:
>   - please avoid using scsi.h and hosts.h from drivers/scsi 
> in favour of
>     the include/scsi/ headers, especially get rid of all the Scsi_Foo
>     typedefs
ok

Re: [ANNOUNCE][RELEASE]: megaraid unified driver version 2.20.0.B 1

[Jeff Garzik]

Mukker, Atul wrote:
>>megaraid_clib.c:
>>  - why do you need the scb pool managment code at all?  You 
>>can dynamically
>>    allocate scbs in ->queuecommand
> 
> Will do. Please see the follow up question below

If there is a static maximum of scbs for megaraid hardware, dynamically 
allocating scbs in ->queuecommand is a waste of time.

In my drivers, I pre-allocate driver-specific per-request structures -- 
just like the SCSI layer does ;-)

If you follow this -- faster -- approach, make sure you don't waste a 
lot of memory with pre-allocated scb's you'll rarely use.


>>  - can you explain the need for all the mraid_pci_blk_pool?  
>>I.e. why the
>>    generic dma pool routines don't work for megaraid
> 
> We did not want to use pci_alloc_consistent because it would give one page
> even if we need 16 bytes (and we need a lot of these). Also, the
> pci_poo_create and pci_pool_alloc would fail on some setups - maybe because
> the driver requires lots of small chunks of DMAable buffers. So we decided
> to write wrapper functions over pci_alloc_consistent..

Would prefer to identify the root cause of pci_pool_xxx failure, since 
that is the proper API to use.

	Jeff

Re: [ANNOUNCE][RELEASE]: megaraid unified driver version 2.20.0.B 1

[Jeff Garzik]

Jeff Garzik wrote:
> If there is a static maximum of scbs for megaraid hardware, dynamically 
> allocating scbs in ->queuecommand is a waste of time.
> 
> In my drivers, I pre-allocate driver-specific per-request structures -- 
> just like the SCSI layer does ;-)

Slight correction... it looks like SCSI dynamically allocates requests 
these days.

That doesn't change my core argument, however.

	Jeff

RE: [ANNOUNCE][RELEASE]: megaraid unified driver version 2.20.0.B 1

[Mukker, Atul]

>OK, I have started to look at this driver, I have come across one
Good!

>problem, which the attached patch fixes. This patch has been sent
>through the list several times and has been accepted into 2.6.5.
Taken, would be added asap

>1. The Kconfig.megaraid and Makefile.2.6 files from the alpha release
>are not in the beta.
Will be added in next drop

>2. In mraid_pci_blk_pool_destroy(), the caller "guarantees that no more
>memory from the pool is in use", however, they don't have to guarantee
>that pool is not null. Why? In fact, in the code it appears that this
>guarantee is also made...
Now you are reading between the lines :-) Just consider clib to be
independently implemented and has some safety checks

>3. I am not sure what the local conventions on this are, but in
>megaraid_alloc_cmd_packets() if the first allocation fails then we
>return straight away, in all other cases we do a goto fail_alloc_cmds;
Accepted..

>4. Also a consistency issue: In megaraid_mbox_mm_cmd() we handle the
>deletion of a logical drive specially, by calling
>megaraid_mbox_del_logdrv(), which just ensures that the drives are
Good catch.

Thanks!
-Atul Mukker
LSI Logic