[netdrivers] Re: sundance.c : forcing mac address does not work

[Donald Becker]

On Thu, 6 Feb 2003, Philippe De Muyter wrote:

> Feel free to redirect my mail to a more approriate mailing list if needed.

I'll Cc: this to the netdrivers list.

> I now come back to my original goal.  I use the 4 channels of that board
> as a bonding channel, and now (with the fixed MAC address) it works,
> but the performances are disappointing.  For ftp or nfs transfers I can reach
> only 14 Mb/s between two idle Pentium III 1266MHz with 1Gb mem.

Presumably it works at full speed with one interface, correct?

I can guess two reasons:
  The bonding driver does a bad job of load balancing.
     My original bonding driver used blind round-robin until the driver
     queues filled, and only then looked at how busy the device was.
     Looking for idle channels to send on is a sure way to get
     unbalanced behavior.
     But this problem just impacts scaling, not actually dropping performance.
  The kernel is running short of memory, and it is made more likely and
     has more of an impact with the four port board used in bonding mode.

Finally, a note: channel bonding only works well when
   the NICs are not overly clever.
   the queueing time is less than the transmit time.
Using channel bonding with gigabit Ethernet is almost never a worthwhile.

> 2.  I have added to cleanup_module() the following lines
> 
>                 get_stats(root_net_dev);
>                 printk("%6s:%lu packets missed, %lu received\n",
> 			root_net_dev->name,
>                         np->stats.rx_missed_errors, np->stats.rx_packets);
> 
> and I get the following in /var/log/messages
> 
> Feb  6 18:50:02 t3tci10 kernel:   eth4:958 packets missed, 61905 received
> Feb  6 18:50:02 t3tci10 kernel:   eth3:937 packets missed, 61925 received
> Feb  6 18:50:02 t3tci10 kernel:   eth2:917 packets missed, 61946 received
> Feb  6 18:50:02 t3tci10 kernel:   eth1:785 packets missed, 62078 received

Acckkk!   That is horrible.

Could you add the following code?
It is a counter on how many allocate attempts failed.  The easy, sleazy
was to implement this is to mis-use the (usually pointless)
'rx_compressed' field in the statistics.
The count will be reported in the "Compressed" field of /proc/net/dev.


In netdev_rx()
	/* Refill the Rx ring buffers. */
	for (; np->cur_rx - np->dirty_rx > 0; np->dirty_rx++) {
		struct sk_buff *skb;
		entry = np->dirty_rx % RX_RING_SIZE;
		if (np->rx_skbuff[entry] == NULL) {
			skb = dev_alloc_skb(np->rx_buf_sz);
			np->rx_skbuff[entry] = skb;
-			if (skb == NULL)
-				break;				/* Better luck next round. */
+			if (skb == NULL) {
+				np->stats.rx_compressed;	/* Mis-use! */
+				break;
+			}
	

-- 
Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Scyld Beowulf cluster system
Annapolis MD 21403			410-990-9993