All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sreekanth Reddy <sreekanth.reddy@avagotech.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: jejb@kernel.org,
	"James E.J. Bottomley" <JBottomley@parallels.com>,
	linux-scsi@vger.kernel.org,
	Sathya Prakash <Sathya.Prakash@avagotech.com>,
	Nagalakshmi Nandigama <Nagalakshmi.Nandigama@avagotech.com>,
	linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support
Date: Mon, 11 Aug 2014 18:47:01 +0530	[thread overview]
Message-ID: <CAK=zhgpGp57nMXeDGsNKg3SHsUc-LV25BtBuCcUBXqXUESzOWQ@mail.gmail.com> (raw)
In-Reply-To: <CAK=zhgpiyt9xukGCNDOpEDmWRwFSMCcEiUQ190BW0UgiLGVP6g@mail.gmail.com>

Hi Martin,

Please let me known any further changes are required so that I can
send this patch once again with git send-email.

Regards,
Sreekanth

On Mon, Aug 11, 2014 at 6:45 PM, Sreekanth Reddy
<sreekanth.reddy@avagotech.com> wrote:
> Hi Martin,
>
> Please let me known any further changes are required so that I can send this
> patch once again with git send-email.
>
> Regards,
> Sreekanth
>
>
> On Wed, Aug 6, 2014 at 10:57 AM, Sreekanth Reddy
> <sreekanth.reddy@avagotech.com> wrote:
>>
>> Hi Martin,
>>
>> Replied inline.
>>
>> On Wed, Aug 6, 2014 at 12:16 AM, Martin K. Petersen
>> <martin.petersen@oracle.com> wrote:
>>>
>>> >>>>> "Sreekanth" == Sreekanth Reddy <sreekanth.reddy@avagotech.com>
>>> >>>>> writes:
>>>
>>> Sreekanth,
>>>
>>> Patch was mangled and I had to apply every single hunk by hand. Please
>>> use git send-email.
>>>
>> Sorry, Next time onwards I will take of this.
>>
>>>
>>> +static int dma_mask;
>>> +
>>> +static int
>>> +_base_wait_for_doorbell_int(struct MPT2SAS_ADAPTER *ioc, int timeout,
>>> +                int sleep_flag);
>>> +static int
>>> +_base_wait_for_doorbell_ack(struct MPT2SAS_ADAPTER *ioc, int timeout,
>>> +                int sleep_flag);
>>> +static int
>>> +_base_wait_for_doorbell_not_used(struct MPT2SAS_ADAPTER *ioc, int
>>> timeout,
>>> +                 int sleep_flag);
>>> +static int
>>> +_base_handshake_req_reply_wait(struct MPT2SAS_ADAPTER *ioc, int
>>> request_bytes,
>>> +    u32 *request, int reply_bytes, u16 *reply, int timeout, int
>>> sleep_flag);
>>> +static int
>>> +_base_get_ioc_facts(struct MPT2SAS_ADAPTER *ioc, int sleep_flag);
>>>
>>> Are you sure you need all these? _base_get_ioc_facts was the only one
>>> that needed to be declared in my original patch.
>>
>>
>> Accepted only _base_get_ioc_facts is needs to be declared here.
>>
>>>
>>>
>>> +    if (ioc->rdpq_array_enable)
>>> +        sz = reply_post_free_sz;
>>> +    else {
>>> +        if (_base_is_controller_msix_enabled(ioc))
>>> +            sz = reply_post_free_sz * ioc->reply_queue_count;
>>> +        else
>>> +            sz = reply_post_free_sz;
>>> +    }
>>>
>>> sz = reply_post_free_sz;
>>> if (_base_is_controller_msix_enabled(ioc) && !ioc->rdpq_array_enable)
>>>    sz *= ioc->reply_queue_count;
>>
>>
>> Accepted. In the next time I will update this in the patch.
>>>
>>>
>>> +    ioc->reply_post = kcalloc((ioc->rdpq_array_enable) ?
>>> +        (ioc->reply_queue_count):1,
>>> +        sizeof(struct reply_post_struct), GFP_KERNEL);
>>>
>>> You're special casing the !rdpq code path again. Why don't you just make
>>> sure reply_queue_count is always correct?
>>
>>
>> Here we are using the reply_post queue to store the base address of the
>> complete reply_post_free queue pool in case of non rdpq support scenario
>> (since here we allocate a complete memory pool of all the reply_queue_count
>> number of reply queues in single shot, so there is only one continuous
>> memory pool). so here the number of entries in the reply_post queue is one
>> in case of non rdpq support scenario.
>>
>> In case of rdpq support scenario reply_post queue will store the base
>> addresses of each and every reply_queue_count number of reply_post_free
>> queue pool. since here we allocate individual and separate reply_post_free
>> memory pool for each msix vector. so here reply_queue_count number of
>> individual reply_post_free queue pools are allocated, so the number of
>> entries in the reply_post queue is reply_queue_count value.
>>
>> So, here the number of entries in the reply_post queue is not dependent on
>> the reply_queue_count but it depends on the the rdpq_support enabled or not.
>> i.e. if rdpq support is enabled then the number of entries in this
>> reply_post queue is reply_queue_count value other wise it is one.
>>
>>>
>>>
>>> +    do {
>>> +        ioc->reply_post[i].reply_post_free =
>>> +            pci_pool_alloc(ioc->reply_post_free_dma_pool,
>>> +            GFP_KERNEL,
>>> +            &ioc->reply_post[i].reply_post_free_dma);
>>> +        if (!ioc->reply_post[i].reply_post_free) {
>>> +            printk(MPT2SAS_ERR_FMT
>>> +            "reply_post_free pool: pci_pool_alloc failed\n",
>>> +            ioc->name);
>>> +            goto out;
>>> +        }
>>> +        memset(ioc->reply_post[i].reply_post_free, 0, sz);
>>> +        dinitprintk(ioc, printk(MPT2SAS_INFO_FMT
>>> +            "reply post free pool (0x%p): depth(%d),"
>>> +            "element_size(%d), pool_size(%d kB)\n", ioc->name,
>>> +            ioc->reply_post[i].reply_post_free,
>>> +            ioc->reply_post_queue_depth, 8, sz/1024));
>>> +        dinitprintk(ioc, printk(MPT2SAS_INFO_FMT
>>> +            "reply_post_free_dma = (0x%llx)\n", ioc->name,
>>> +            (unsigned long long)
>>> +            ioc->reply_post[i].reply_post_free_dma));
>>> +        total_sz += sz;
>>> +    } while (ioc->rdpq_array_enable && (++i < ioc->reply_queue_count));
>>>
>>> Same thing. I think:
>>>
>>>      for (i = 0; i < ioc->reply_queue_count ; i++) {
>>>
>>> was much clearer.
>>
>>
>> I feel do while loop is suitable to reduce the redundancy code between the
>> rdpq support and non rdpq support scenarios.
>>
>> In case of non rdpq support scenario, this loop is executed only once to
>> allocate a continuous single memory pool for all reply_queue_count number of
>> reply_post_free queues.
>>
>> where as in case of rdpq support scenario, this loop is executed
>> reply_queue_count number of times for allocating individual and separate
>> memory pools for each reply_post_free queue.
>>
>>>
>>>
>>> If reply_queue_count is ever inconsistent wrt. ioc->rdpq_array_enable
>>> and _base_is_controller_msix_enabled(ioc) then that's an orthogonal
>>> problem that you should address directly instead of working around it
>>> several places in the code.
>>
>>
>>>
>>> --
>>> Martin K. Petersen      Oracle Linux Engineering
>>
>>
>> Regards,
>> Sreekanth
>
>

  parent reply	other threads:[~2014-08-11 13:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-25 10:34 [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support Reddy, Sreekanth
2014-06-25 10:34 ` Reddy, Sreekanth
2014-07-22  3:10 ` Martin K. Petersen
2014-07-22  3:10   ` Martin K. Petersen
     [not found]   ` <CAK=zhgoQt5J=jh4jShAy5rBXNz34sN-tqf=uZDkY4zQJ9XhM5g@mail.gmail.com>
2014-07-23  1:25     ` Martin K. Petersen
2014-07-23 17:37       ` Sreekanth Reddy
2014-07-23 19:46         ` Martin K. Petersen
2014-07-25 12:57           ` Sreekanth Reddy
2014-07-25 19:43             ` Martin K. Petersen
2014-07-30 14:55               ` Sreekanth Reddy
2014-08-05 18:46                 ` Martin K. Petersen
     [not found]                   ` <CAK=zhgpqW-t11JKiBRRM7Z4TEMyaEUBX943qT8faaKPk6Pk4XA@mail.gmail.com>
     [not found]                     ` <CAK=zhgpiyt9xukGCNDOpEDmWRwFSMCcEiUQ190BW0UgiLGVP6g@mail.gmail.com>
2014-08-11 13:17                       ` Sreekanth Reddy [this message]
2014-08-12  2:32                       ` Martin K. Petersen
2017-04-25 11:51           ` Sreekanth Reddy
2017-04-26 22:25             ` Martin K. Petersen
2017-04-26 22:25               ` Martin K. Petersen
2017-04-27  9:15               ` Kashyap Desai
2014-08-12  9:24 Sreekanth Reddy
2014-08-12  9:37 ` Joe Perches
2014-08-12  9:51   ` Sreekanth Reddy
2014-08-21 20:35 ` Martin K. Petersen
2014-08-23 15:04 [RESEND][PATCH 07/10] [SCSI] mpt2sas: " Sreekanth Reddy
2014-08-24 15:37 ` Christoph Hellwig

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='CAK=zhgpGp57nMXeDGsNKg3SHsUc-LV25BtBuCcUBXqXUESzOWQ@mail.gmail.com' \
    --to=sreekanth.reddy@avagotech.com \
    --cc=JBottomley@parallels.com \
    --cc=Nagalakshmi.Nandigama@avagotech.com \
    --cc=Sathya.Prakash@avagotech.com \
    --cc=hch@infradead.org \
    --cc=jejb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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.