<div dir="ltr"><div><div><div><div>>Do you mean "sufficient" here rather than "efficient"?  It's far less<br>
>inefficient than what the code was previously doing, but still...<br>
<br></div>Yes, I'm gonna send a new fix for the comment patch and<br></div>change the subject of the previous patch soc/qman<br><br></div>Thanks,<br></div>Karim<br><div><div><div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 June 2017 at 04:49, Scott Wood <span dir="ltr"><<a href="mailto:oss@buserror.net" target="_blank">oss@buserror.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, May 05, 2017 at 10:05:56AM +0200, Karim Eshapa wrote:<br>
> Change the comment for an entry check inside function<br>
> drain_mr_fqrni() with sleep for sufficient period<br>
> of time instead of long time proccessor cycles.<br>
><br>
> Signed-off-by: Karim Eshapa <<a href="mailto:karim.eshapa@gmail.com">karim.eshapa@gmail.com</a>><br>
> ---<br>
>  drivers/soc/fsl/qbman/qman.c | 25 +++++++++++++------------<br>
>  1 file changed, 13 insertions(+), 12 deletions(-)<br>
><br>
> diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c<br>
> index 18d391e..636a7d7 100644<br>
> --- a/drivers/soc/fsl/qbman/qman.c<br>
> +++ b/drivers/soc/fsl/qbman/qman.c<br>
> @@ -1071,18 +1071,19 @@ static int drain_mr_fqrni(struct qm_portal *p)<br>
>       msg = qm_mr_current(p);<br>
>       if (!msg) {<br>
>               /*<br>
> -              * if MR was full and h/w had other FQRNI entries to produce, we<br>
> -              * need to allow it time to produce those entries once the<br>
> -              * existing entries are consumed. A worst-case situation<br>
> -              * (fully-loaded system) means h/w sequencers may have to do 3-4<br>
> -              * other things before servicing the portal's MR pump, each of<br>
> -              * which (if slow) may take ~50 qman cycles (which is ~200<br>
> -              * processor cycles). So rounding up and then multiplying this<br>
> -              * worst-case estimate by a factor of 10, just to be<br>
> -              * ultra-paranoid, goes as high as 10,000 cycles. NB, we consume<br>
> -              * one entry at a time, so h/w has an opportunity to produce new<br>
> -              * entries well before the ring has been fully consumed, so<br>
> -              * we're being *really* paranoid here.<br>
> +              * if MR was full and h/w had other FQRNI entries to<br>
> +              * produce, we need to allow it time to produce those<br>
> +              * entries once the existing entries are consumed.<br>
> +              * A worst-case situation (fully-loaded system) means<br>
> +              * h/w sequencers may have to do 3-4 other things<br>
> +              * before servicing the portal's MR pump, each of<br>
> +              * which (if slow) may take ~50 qman cycles<br>
> +              * (which is ~200 processor cycles). So sleep with<br>
> +              * 1 ms would be very efficient, after this period<br>
> +              * we can check if there is something produced.<br>
> +              * NB, we consume one entry at a time, so h/w has<br>
> +              * an opportunity to produce new entries well before<br>
> +              * the ring has been fully consumed.<br>
<br>
</div></div>Do you mean "sufficient" here rather than "efficient"?  It's far less<br>
inefficient than what the code was previously doing, but still...<br>
<br>
Otherwise, looks good.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Scott<br>
</font></span></blockquote></div><br></div>