<br>
<br><tt><font size=2>openib-general-bounces@openib.org wrote on 11/14/2006
03:18:23 PM:<br>
<br>
>     Shirley> The rotting packet situation consistently
happens for<br>
>     Shirley> ehca driver. The napi could poll forever
with your<br>
>     Shirley> original patch. That's the reason I defer
the rotting<br>
>     Shirley> packet process in next napi poll.<br>
> <br>
> Hmm, I don't see it.  In my latest patch, the poll routine does:<br>
> <br>
> repoll:<br>
>    done  = 0;<br>
>    empty = 0;<br>
> <br>
>    while (max) {<br>
>       t = min(IPOIB_NUM_WC, max);<br>
>       n = ib_poll_cq(priv->cq, t, priv->ibwc);<br>
> <br>
>       for (i = 0; i < n; ++i) {<br>
>          if (priv->ibwc[i].wr_id &
IPOIB_OP_RECV) {<br>
>             ++done;<br>
>             --max;<br>
>             ipoib_ib_handle_rx_wc(dev,
priv->ibwc + i);<br>
>          } else<br>
>             ipoib_ib_handle_tx_wc(dev,
priv->ibwc + i);<br>
>       }<br>
> <br>
>       if (n != t) {<br>
>          empty = 1;<br>
>          break;<br>
>       }<br>
>    }<br>
> <br>
>    dev->quota -= done;<br>
>    *budget    -= done;<br>
> <br>
>    if (empty) {<br>
>       netif_rx_complete(dev);<br>
>       if (unlikely(ib_req_notify_cq(priv->cq,<br>
>                    
 IB_CQ_NEXT_COMP |<br>
>                    
 IB_CQ_REPORT_MISSED_EVENTS)) &&<br>
>           netif_rx_reschedule(dev, 0))<br>
>          goto repoll;<br>
> <br>
>       return 0;<br>
>    }<br>
> <br>
>    return 1;<br>
> <br>
> so every receive completion will count against the limit set by the<br>
> variable max.  The only way I could see the driver staying in
the poll<br>
> routine for a long time would be if it was only processing send<br>
> completions, but even that doesn't actually seem bad: the driver is<br>
> making progress handling completions.<br>
> </font></tt>
<br>
<br><tt><font size=2>Is it possible that when one gets into the "rotting
packet" case, the quota</font></tt>
<br><tt><font size=2>is at or close to 0 (on ehca). If in the cass it is
0 and netif_rx_reschedule() </font></tt>
<br><tt><font size=2>case wins (over netif_rx_schedule()) then it keeps
spinning unable to process </font></tt>
<br><tt><font size=2>any packets since the undo parameter for netif_reschedule()
is 0.</font></tt>
<br>
<br><tt><font size=2>If netif_rx_reschedule() keeps winning for a few iterations
then the receive</font></tt>
<br><tt><font size=2>queues get full and dropping packets, thus causing
a loss in performance.</font></tt>
<br>
<br><tt><font size=2>If this is indeed the case, then one option to try
out may be is to change </font></tt>
<br><tt><font size=2>the undo parameter of netif_rx_rechedule()to either
IB_WC or even dev->weight.</font></tt>
<br>
<br>
<br><tt><font size=2><br>
>     Shirley> It does help the performance from 1XXMb/s
to 7XXMb/s, but<br>
>     Shirley> not as expected 3XXXMb/s.<br>
> <br>
> Is that 3xxx Mb/sec the performance you see without the NAPI patch?<br>
> <br>
>     Shirley> With the defer rotting packet process patch,
I can see<br>
>     Shirley> packets out of order problem in TCP layer.
 Is it<br>
>     Shirley> possible there is a race somewhere causing
two napi polls<br>
>     Shirley> in the same time? mthca seems to use irq
auto affinity,<br>
>     Shirley> but ehca uses round-robin interrupt.<br>
> <br>
> I don't see how two NAPI polls could run at once, and I would expect<br>
> worse effects from them stepping on each other than just out-of-order<br>
> packets.  However, the fact that ehca does round-robin interrupt<br>
> handling might lead to out-of-order packets just because different<br>
> CPUs are all feeding packets into the network stack.<br>
> <br>
>  - R.<br>
> <br>
> _______________________________________________<br>
> openib-general mailing list<br>
> openib-general@openib.org<br>
> http://openib.org/mailman/listinfo/openib-general<br>
> <br>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general<br>
> <br>
</font></tt>