All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: jamal <hadi@cyberus.ca>
Cc: netdev@oss.sgi.com
Subject: Re: packet re-ordering on SMP machines.
Date: Sun, 25 Aug 2002 11:32:18 -0700	[thread overview]
Message-ID: <3D6922B2.1020400@candelatech.com> (raw)
In-Reply-To: Pine.GSO.4.30.0208251149320.29461-100000@shell.cyberus.ca


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@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

  reply	other threads:[~2002-08-25 18:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-25 15:56 packet re-ordering on SMP machines jamal
2002-08-25 18:32 ` Ben Greear [this message]
2002-08-26  0:52   ` jamal
2002-08-26  4:34     ` Ben Greear
2002-08-26 11:20       ` jamal
2002-08-26 23:03       ` Xiaoliang (David) Wei
2002-08-26 23:20         ` Ben Greear
2002-08-27 10:59         ` jamal
2002-08-27 11:12           ` Andi Kleen
2002-08-27 12:05             ` jamal
2002-08-27 12:20               ` Andi Kleen
2002-08-27 13:06                 ` kuznet
2002-08-27 13:13                   ` Andi Kleen
2002-08-27 13:24                     ` kuznet
2002-09-15  8:42                     ` Harald Welte
2002-09-15 21:55                       ` Alexey Kuznetsov
2002-08-27 17:22                 ` Cheng Jin
2002-08-27 17:33                   ` Andi Kleen
2002-08-27 19:43               ` Xiaoliang (David) Wei
  -- strict thread matches above, loose matches on Subject: below --
2002-08-25 15:56 jamal
2002-08-25  8:01 Manfred Spraul
2002-08-25  7:18 Ben Greear
2002-08-25  7:07 ` David S. Miller
2002-08-25 14:41 ` Alan Cox
2002-08-25 17:00   ` Ben Greear
2002-08-25 20:44     ` Alan Cox
2002-08-25 22:49   ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D6922B2.1020400@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=hadi@cyberus.ca \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.