netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: jamal <hadi@cyberus.ca>
Cc: Chris Friesen <cfriesen@nortelnetworks.com>,
	Cacophonix <cacophonix@yahoo.com>,
	linux-net@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: bonding vs 802.3ad/Cisco EtherChannel link agregation
Date: Tue, 17 Sep 2002 21:06:45 -0700	[thread overview]
Message-ID: <3D87FBD5.3030508@candelatech.com> (raw)
In-Reply-To: Pine.GSO.4.30.0209172100361.3686-100000@shell.cyberus.ca

jamal wrote:
> 
> On Tue, 17 Sep 2002, Ben Greear wrote:
> 
> 
>>I have a program that sends and receives UDP packets with 32-bit sequence
>>numbers.  I can detect OOO packets if they fit into the last 10 packets
>>received.  If they are farther out of order than that, the code treats
>>them as dropped....
>>
> 
> 
> So let me understand this:
> You have a packet going out eth0 looped back to eth0 and you are seeing

I go out eth2 and come in eth3, both e1000 copper nics.

> reordering? What sort of things are happening from departure at udp socket
> to arrival on the other side? Are you doing anything funky yourself or
> it is all kernel?

I see reordering on regular old socket calls from user space, and I see
the same thing with pktgen packets as well (which clears the stack of fault).

For user space, I am binding to source IP, setting SO_BINDTODEVICE, and O_NONBLOCK.
Nothing overly weird I believe.

pktgen has its own ways, basically it grabs the pkts in the dev.c receive method
near where the bridging code grabs it's packets...

I see no reordering at all with tulip 4-port nics and single processor machines.

> 
> 
>>I used smp_afinity to tie a NIC to a CPU, and the napi patch for 2.4.20-pre7.
> 
> 
> Did you get reordering with affinity?

Yes.  I'm not sure I tried affinity w/out NAPI though.  I definately tried
it with NAPI and saw reordering.

> 
> 
>>When sending and receiving 250Mbps of UDP/IP traffic (sending over cross-over
>>cable to other NIC on same machine), I see the occasional OOO packet.  I also
>>see bogus dropped packets, which means sometimes the order is off by 10 or more
>>packets....
> 
> 
> A lot of shit is happening at that rate in particular with PCI bus. If
> i understood correctly a packet crosses the bus about 4 times?

Two times I believe, but I'm sending in both directions, so there is about
1Gbps across the bus, not even counting the UDP, IP, and Ethernet headers.

> 
> 
>>The other fun thing about this setup is that after running around 65 billion bytes
>>with this test, the machine crashes with an OOPs.
> 
> 
> No clue whats going on - probably a race somewhere and cant help since
> i dont have this NIC but if you get Robert excited he might be able to
> help you.

He seems moderately interested, suggested I try the one in 2.5.[latest].
I'll be able to do that next week, assuming it's trivial to compile it
for 2.4.19....

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-09-18  4:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-12 18:39 bonding vs 802.3ad/Cisco EtherChannel link agregation Boris Protopopov
2002-09-12 23:34 ` David S. Miller
2002-09-13 14:29   ` Chris Friesen
2002-09-13 22:22     ` Cacophonix
2002-09-16 13:23       ` Chris Friesen
2002-09-16 16:09         ` Ben Greear
2002-09-16 19:55           ` David S. Miller
2002-09-16 21:10             ` Chris Friesen
2002-09-16 21:04               ` David S. Miller
2002-09-16 21:22                 ` Chris Friesen
2002-09-16 21:17                   ` David S. Miller
2002-09-17 10:16           ` jamal
2002-09-17 16:43             ` Ben Greear
2002-09-18  1:07               ` jamal
2002-09-18  4:06                 ` Ben Greear [this message]
2002-09-18 11:48                   ` jamal
  -- strict thread matches above, loose matches on Subject: below --
2002-09-13  1:30 Feldman, Scott
2002-09-13 14:50 ` Boris Protopopov
2002-09-16 20:12 Yan-Fa Li

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=3D87FBD5.3030508@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=cacophonix@yahoo.com \
    --cc=cfriesen@nortelnetworks.com \
    --cc=hadi@cyberus.ca \
    --cc=linux-net@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).