lkml.org 
[lkml]   [2017]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 13/18] rpmsg: glink: Add rx done command
From
Date


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
>

\
 
 \ /
  Last update: 2017-08-23 06:45    [W:0.257 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site