Shirley> From the code work through, if defering rotting packet
Shirley> process by return (missed_event &&
Shirley> netif_rx_reschedule(dev, 0)); Then the same dev->poll can
Shirley> be added to per cpu poll list twice: one is from
Shirley> netif_rx_reschedule, one is from napi return 1. That
Shirley> might explains packets out of order: when one poll
Shirley> finishes and reset LINK SCHED bit and the next interrupt
Shirley> runs on other cpu.
I don't think so. It's completely normal for dev->poll() to return 1
when there's more work to be done, so the networking core will just
move the device to the tail of the poll list. So I don't see why it
would make a difference if we actually do any work after
netif_rx_reschedule() or not.
On the other hand I still don't see why it helps to drop out of the
poll routine immediately even though we know there is more work to be
done, and the networking stack has told us it could handle more packets.
- R.
_______________________________________________
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
