<html><body>
<p><tt>Roland Dreier <rdreier@cisco.com> wrote on 11/13/2006 08:45:52 AM:<br>
<br>
> > Sorry I was not intend to send previous email. Anyway I accidently sent it<br>
> > out. What I thought was there would be a problem, if the missed_event<br>
> > always return to 1. Then this napi poll would keep forever.<br>
> <br>
> Well, it's limited by the quota that the net stack gives it, so<br>
> there's no possibility of looping forever. However....<br>
><br>
> > How about defer the rotting packets process later? like this:<br>
> <br>
> that seems like it is still correct.<br>
> <br>
> > With this patch, I could get NAPI + non scaling code throughput performance<br>
> > from 1XXMb/s to 7XXMb/s, anyway there are some other problems I am still<br>
> > investigating now.<br>
> <br>
> But I wonder why it gives you a factor of 4 in performance?? Why does<br>
> it make a difference? I would have thought that the rotting packet<br>
> situation would be rare enough that it doesn't really matter for<br>
> performance exactly how we handle it.<br>
> <br>
> What are the other problems you're investigating?<br>
> <br>
> - R.<br>
</tt><br>
The rotting packet situation consistently happens for ehca driver. The napi could poll forever with your original patch. That's the reason I defer the rotting packet process in next napi poll. It does help the performance from 1XXMb/s to 7XXMb/s, but not as expected 3XXXMb/s. With the defer rotting packet process patch, I can see packets out of order problem in TCP layer. Is it possible there is a race somewhere causing two napi polls in the same time? mthca seems to use irq auto affinity, but ehca uses round-robin interrupt.<br>
<br>
Thanks<br>
Shirley Ma</body></html>