DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org C641F6025C
Subject: Re: [PATCH 13/18] rpmsg: glink: Add rx done command
To: Sricharan R <sricharan@codeaurora.org>, ohad@wizery.com,
        bjorn.andersson@linaro.org, linux-remoteproc@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org
References: <1502903951-5403-1-git-send-email-sricharan@codeaurora.org>
 <1502903951-5403-14-git-send-email-sricharan@codeaurora.org>
 <a5f890fe-7405-ff03-9a43-0e4d62683cb6@codeaurora.org>
 <67a2b4db-fabb-9787-6813-7bd001814bfc@codeaurora.org>
From: Arun Kumar Neelakantam <aneela@codeaurora.org>
Message-ID: <6b36382b-8889-0a10-d276-fe6d5bd1874e@codeaurora.org>
Date: Wed, 23 Aug 2017 10:14:44 +0530
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <67a2b4db-fabb-9787-6813-7bd001814bfc@codeaurora.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1624
Lines: 35


On 8/22/2017 7:46 PM, Sricharan R wrote:
> Hi,
>>> +    /* Take it off the tree of receive intents */
>>> +    if (!intent->reuse) {
>>> +        spin_lock(&channel->intent_lock);
>>> +        idr_remove(&channel->liids, intent->id);
>>> +        spin_unlock(&channel->intent_lock);
>>> +    }
>>> +
>>> +    /* Schedule the sending of a rx_done indication */
>>> +    spin_lock(&channel->intent_lock);
>>> +    list_add_tail(&intent->node, &channel->done_intents);
>>> +    spin_unlock(&channel->intent_lock);
>>> +
>>> +    schedule_work(&channel->intent_work);
>> Adding one more parallel path will hit performance, if this worker could not get CPU cycles
>> or blocked by other RT or HIGH_PRIO worker on global worker pool.
>   The idea is, by design to have parallel non-blocking paths for rx and tx (that is done as a
>   part of rx by sending the rx_done command), otherwise trying to send the rx_done
>   command in the rx isr context is a problem since the tx can wait for the FIFO space and
>   in worst case, can even lead to a potential deadlock if both the local and remote try
>   the same. Having said that, instead of queuing this work in to the global queue, this
>   can be put in to a local glink edge owned queue (or) a threaded isr ?, downstream does the
>   rx_done in a client specific worker.

Yes, mixing RX and TX path will cause dead lock. I am okay to use 
specific queue with HIGH_PRIO or a threaded isr.
down stream uses both client specific worker and client RX cb [this mix 
the TX and RX path] which want to avoid.
>
> Regards,
>   Sricharan
>