jamal wrote:
>
>
>
> NAPI fixes packet reordering problems.
It does indeed. I just patched the e1000 with the latest NAPI patch
I could find (from Aug 15 or so), and the re-ordering problems went away.
The amount of packets dropped decreased too, but I still see about 1 out of
1000 packets dropped due to rx-FIFO or rx-dropped. This is when trying to run
60,000 pps of 1514 byte packets from one port to the other on the same
dual-port e1000
NIC (copper). It will generate up to about 72,000 pps without dropping too many
more...
I will do some more tests on two single-port NICs soon to see if that
performs better.
Also, I see the hard_start_xmit call failing 5876 times out of 2719493
calls (for example). The code that calls the method looks like this:
spin_lock_bh(&odev->xmit_lock);
if (!netif_queue_stopped(odev)) {
if (odev->hard_start_xmit(next->skb, odev)) {
if (net_ratelimit()) {
printk(KERN_INFO "Hard xmit
error\n");
}
next->errors++;
next->last_ok = 0;
}
else {
next->last_ok = 1;
next->sofar++;
next->tx_bytes += (next->cur_pkt_size
+ 4); /* count csum */
}
next->next_tx_ns = getRelativeCurNs() +
next->ipg;
}
else { /* Re-try it next time */
next->last_ok = 0;
}
spin_unlock_bh(&odev->xmit_lock);
I have not seen hard_start_xmit fail on other drivers, even when over-driving
them
well beyond their capabilities. Any ideas what causes the hard_start_xmit
errors?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
|