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

[Philippe De Muyter]

Donald Becker wrote :
> 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! */

I surmised that you meant '++' :
  +				np->stats.rx_compressed++;	/* Mis-use! */

> +				break;
> +			}

but I get only 0 in the 'compressed' field ( bond0 is eth2 + eth3 + eth4 + eth5 ) :

	Inter-|   Receive                                                |  Transmit
	 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
	    lo: 1985764   17758    0    0    0     0          0         0  1985764   17758    0    0    0     0       0          0
	  eth0: 2645954   54353    0    0    0     0          0         0   697874    7707    0    0    0     0       0          0
	  eth1:       0       0    0    0    0     0          0         0  1081206   17781    0    0    0     0       0          0
	  sit0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
	  eth2:93736019   62007    0  847    0     0          0         0  3815562   54027    0    0    0     0       0          0
	  eth3:93581650   61904    0  950    0     0          0         0  3816650   54027    0    0    0     0       0          0
	  eth4:93600188   61923    0  931    0     0          0         0  3814748   54027    0    0    0     0       0          0
	  eth5:93456302   61836    0 1018    0     0          0         0  3814633   54026    0    0    0     0       0          0
	 bond0:374374159  247670    0 3746    0     0          0         0 15261593  216107    0    0    0     0       0          0


It seems to me that load-balancing is perfect.


Should I increase RX_RING_SIZE to 64 or more ?

Philippe De Muyter  phdm@macqel.be  Tel +32 27029044
Macq Electronique SA  rue de l'Aeronef 2  B-1140 Bruxelles  Fax +32 27029077