Bug 644438

Description of problem:

The bnx2 NIC changes the packet received ordering.

This is a simple reproducer script:

#!/usr/bin/perl -w
use strict;
use IO::Socket::Multicast;

# create a new UDP socket ready to read datagrams on port 1100
my $s = IO::Socket::Multicast->new(LocalPort=>1100);

# Add a multicast group
$s->mcast_add('225.0.1.1');

# Set outgoing interface to eth0
$s->mcast_if('eth0');

# Multicast a message to group 225.0.0.1
my $data1 = "1" x 5000;
my $data2 = "1" x 200;

$s->mcast_send($data1, '225.0.0.1:1200');
$s->mcast_send($data2, '225.0.0.1:1200');

Running it on a hp box with a e1000g driver loaded (for output of the data) and a ibm x3650m2 with a bnx2 driver loaded (non bonded) for receiving. 
If you run the script a few times, the receiving side reorders the udp packets sometimes.

The problem doesn't happen disabling MSI (disables multiqueue too)

Version-Release number of selected component (if applicable):
kernel-2.6.18-194.11.4.el5

How reproducible:
Frequently, just run the script few times monitoring the traffic dump.

Although the UDP protocol doesn't guarantee the packet ordering, the NIC shouldn't change the order of received packets.

This is the piece of code from netdev-2.6 enabling the RSS hashing:
5221 static void
5222 bnx2_init_all_rings(struct bnx2 *bp)
5223 {
5224         int i;
5225         u32 val;
...
5258                 val = BNX2_RLUP_RSS_CONFIG_IPV4_RSS_TYPE_ALL_XI |
5259                       BNX2_RLUP_RSS_CONFIG_IPV6_RSS_TYPE_ALL_XI;
5260 
5261                 REG_WR(bp, BNX2_RLUP_RSS_CONFIG, val);
5262 
5263         }
5264 }

If I understand that correctly, all protocols running on top of IPV4 and IPV6 (i.e. UDP) will be hashed and queued in multiples queues.

However, I see in the reproducer script the following:
...
# Multicast a message to group 225.0.0.1
my $data1 = "1" x 5000;
my $data2 = "1" x 200; 
...

which would cause the packet to be fragmented. The fragmentation seems to be  causing the network flow to be broken into two streams, one for fragmented, and one for non-fragmented and this in turn is causing out-of-order issues. Thus, this looks similar to bz#613780 (igb)