[patch 05/13] remove last_rx update from loopback device

[patch 05/13] remove last_rx update from loopback device

[akpm]

From: Christoph Lameter <christoph@graphe.net>

The last_rx field in the loopback driver is updated on every xmit but is
not used otherwise.  Accesses to ->last_rx cause unecessary traffic on the
interlink for NUMA systems which limits the performance of the loopback
device.

The comment given at include/linux/netdevice.h says that last_rx may be
used for future network-power-down code, which is likely not relevant for
the loopback device (please let me know if it is otherwise ..).

Signed-off-by: Niraj Kumar <nirajk@calsoftinc.com>
Signed-off-by: Christoph Lameter <christoph@lameter.com>
Signed-off-by: Shai Fultheim <Shai@Scalex86.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 25-akpm/drivers/net/loopback.c |    2 --
 1 files changed, 2 deletions(-)

diff -puN drivers/net/loopback.c~remove-last_rx-update-from-loopback-device drivers/net/loopback.c
--- 25/drivers/net/loopback.c~remove-last_rx-update-from-loopback-device	Tue Mar 15 14:19:53 2005
+++ 25-akpm/drivers/net/loopback.c	Tue Mar 15 14:19:53 2005
@@ -144,8 +144,6 @@ static int loopback_xmit(struct sk_buff 
 		return 0;
 	}
 
-	dev->last_rx = jiffies;
-
 	lb_stats = &per_cpu(loopback_stats, get_cpu());
 	lb_stats->rx_bytes += skb->len;
 	lb_stats->tx_bytes += skb->len;
_

Re: [patch 05/13] remove last_rx update from loopback device

[Jeff Garzik]

akpm@osdl.org wrote:
> From: Christoph Lameter <christoph@graphe.net>
> 
> The last_rx field in the loopback driver is updated on every xmit but is
> not used otherwise.  Accesses to ->last_rx cause unecessary traffic on the
> interlink for NUMA systems which limits the performance of the loopback
> device.
> 
> The comment given at include/linux/netdevice.h says that last_rx may be
> used for future network-power-down code, which is likely not relevant for
> the loopback device (please let me know if it is otherwise ..).
> 
> Signed-off-by: Niraj Kumar <nirajk@calsoftinc.com>
> Signed-off-by: Christoph Lameter <christoph@lameter.com>
> Signed-off-by: Shai Fultheim <Shai@Scalex86.org>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
> 
>  25-akpm/drivers/net/loopback.c |    2 --
>  1 files changed, 2 deletions(-)
> 
> diff -puN drivers/net/loopback.c~remove-last_rx-update-from-loopback-device drivers/net/loopback.c
> --- 25/drivers/net/loopback.c~remove-last_rx-update-from-loopback-device	Tue Mar 15 14:19:53 2005
> +++ 25-akpm/drivers/net/loopback.c	Tue Mar 15 14:19:53 2005
> @@ -144,8 +144,6 @@ static int loopback_xmit(struct sk_buff 
>  		return 0;
>  	}
>  
> -	dev->last_rx = jiffies;
> -
>  	lb_stats = &per_cpu(loopback_stats, get_cpu());
>  	lb_stats->rx_bytes += skb->len;
>  	lb_stats->tx_bytes += skb->len;

I disagree.  loopback.c is doing precisely what it should be doing.

	Jeff

Re: [patch 05/13] remove last_rx update from loopback device

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> > -	dev->last_rx = jiffies;
> > -
> >  	lb_stats = &per_cpu(loopback_stats, get_cpu());
> >  	lb_stats->rx_bytes += skb->len;
> >  	lb_stats->tx_bytes += skb->len;
> 
> I disagree.  loopback.c is doing precisely what it should be doing.

Nothing actually seems to use last_rx?

Re: [patch 05/13] remove last_rx update from loopback device

[David S. Miller]

On Tue, 15 Mar 2005 15:08:09 -0800
Andrew Morton <akpm@osdl.org> wrote:

> Jeff Garzik <jgarzik@pobox.com> wrote:
> >
> > > -	dev->last_rx = jiffies;
> > > -
> > >  	lb_stats = &per_cpu(loopback_stats, get_cpu());
> > >  	lb_stats->rx_bytes += skb->len;
> > >  	lb_stats->tx_bytes += skb->len;
> > 
> > I disagree.  loopback.c is doing precisely what it should be doing.
> 
> Nothing actually seems to use last_rx?

For one thing bonding load balancing uses it.

You can argue that bonding of loopback devices is silly.
But there are other things one might be able to do with
last_rx and the fact that every driver faithfully sets
it means that it's a reliable metric to use without
special cases.

These loopback driver SMP optimizations are starting to really
driver me crazy.

Re: [patch 05/13] remove last_rx update from loopback device

[Rick Jones]

> These loopback driver SMP optimizations are starting to really
> driver me crazy.

Correct or not, I suspect there are a non-trivial number of folks out there who 
use loopback performance as an indicator of over the network performance or at 
least of stack path length (less driver).  particularly when they have only one 
system and want to make quick (and so worth all the time they put into it) 
comparisons between OSes.

Perhaps that is a driver-ing (since punning drive/driver seems to be the order N 
squared of the day) force behind the changes?

rick jones

Re: [patch 05/13] remove last_rx update from loopback device

[David S. Miller]

On Tue, 15 Mar 2005 17:04:23 -0800
Rick Jones <rick.jones2@hp.com> wrote:

> Perhaps that is a driver-ing (since punning drive/driver seems to be the order N 
> squared of the day) force behind the changes?

Every time the SGI guys with the 512 cpu machine find some shared
memory reference they think they can legitimately remove, they
try to do so.

Re: [patch 05/13] remove last_rx update from loopback device

[Nivedita Singhvi]

Rick Jones wrote:

>> These loopback driver SMP optimizations are starting to really
>> driver me crazy.
> 
> 
> Correct or not, I suspect there are a non-trivial number of folks out 
> there who use loopback performance as an indicator of over the network 
> performance or at least of stack path length (less driver).

I hope not the former. Given that loopback performance is
*significantly* faster than network performance, increasing the
performance of the loopback driver in these somewhat artificial
ways (that differ from the real network device path) simply
*increases* the inaccuracy of their testing and the conclusions
they can draw from it ;).

thanks,
Nivedita

Re: [patch 05/13] remove last_rx update from loopback device

[Rick Jones]

Nivedita Singhvi wrote:
> Rick Jones wrote:
> 
>>> These loopback driver SMP optimizations are starting to really
>>> driver me crazy.
>>
>>
>>
>> Correct or not, I suspect there are a non-trivial number of folks out 
>> there who use loopback performance as an indicator of over the network 
>> performance or at least of stack path length (less driver).
> 
> 
> I hope not the former. Given that loopback performance is
> *significantly* faster than network performance, increasing the
> performance of the loopback driver in these somewhat artificial
> ways (that differ from the real network device path) simply
> *increases* the inaccuracy of their testing and the conclusions
> they can draw from it ;).

I suspect the idea is that if loopback on Platform A is faster than loopback on 
Platform B, then over the network will be faster (or at least more efficient) on 
Platform A than it is on Platform B.

It is indeed fraught with numerous pitfalls - different MTU's, shorticircuting 
at different places etc etc.

I do not claim to condone (even if I'm sometimes forced into that situation 
myself :( ) merely to explain.

As for the 512 CPU machine mentioned in another message, at the rate cores per 
die may increase over the next few years, that may not really be all that large 
a box... :)

rick jones