[RFC] vlan: GRO rx statistics

[RFC] vlan: GRO rx statistics

[Eric Dumazet]

It seems vlan interfaces with hardware-assisted VLAN reception 
dont have rx statistics.

Following patch cures the problem for me but I have no idea
if it is correct ?

Another problem about all rx stats is about multi rx queues devices.
Several cpus can access these counters in parallel ?


diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 8d5ca2a..e13b007 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -89,6 +89,11 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
 	if (!skb->dev)
 		goto drop;
 
+	skb->dev->stats.rx_packets++;
+	skb->dev->stats.rx_bytes += skb->len;
+	if (skb->pkt_type == PACKET_MULTICAST)
+		skb->dev->stats.multicast++;
+
 	for (p = napi->gro_list; p; p = p->next) {
 		NAPI_GRO_CB(p)->same_flow =
 			p->dev == skb->dev && !compare_ether_header(

Re: [RFC] vlan: GRO rx statistics

[Eric Dumazet]

Eric Dumazet a écrit :
> It seems vlan interfaces with hardware-assisted VLAN reception 
> dont have rx statistics.
> 
> Following patch cures the problem for me but I have no idea
> if it is correct ?
> 
> Another problem about all rx stats is about multi rx queues devices.
> Several cpus can access these counters in parallel ?
> 
> 
> diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
> index 8d5ca2a..e13b007 100644
> --- a/net/8021q/vlan_core.c
> +++ b/net/8021q/vlan_core.c
> @@ -89,6 +89,11 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
>  	if (!skb->dev)
>  		goto drop;
>  
> +	skb->dev->stats.rx_packets++;
> +	skb->dev->stats.rx_bytes += skb->len;
> +	if (skb->pkt_type == PACKET_MULTICAST)
> +		skb->dev->stats.multicast++;
> +
>  	for (p = napi->gro_list; p; p = p->next) {
>  		NAPI_GRO_CB(p)->same_flow =
>  			p->dev == skb->dev && !compare_ether_header(
> 

Replying to myself, I found root of the problem and posted a fix.

Still the race while updating dev->stats.tx_{bytes|packets} should be addressed eventually...

Re: [RFC] vlan: GRO rx statistics

[Eric Dumazet]

Eric Dumazet a écrit :

> Still the race while updating dev->stats.tx_{bytes|packets} should be addressed eventually...

Sorry, I meant dev->stats.rx_{bytes|packets}, since tx side is protected by txq spinlock.

Re: [RFC] vlan: GRO rx statistics

[Herbert Xu]

On Fri, Nov 13, 2009 at 05:41:21PM +0100, Eric Dumazet wrote:
>
> Replying to myself, I found root of the problem and posted a fix.

Just curious, do you have a link to that fix?

> Still the race while updating dev->stats.tx_{bytes|packets} should be addressed eventually...

Well making it per-napi_struct should do the trick.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC] vlan: GRO rx statistics

[Eric Dumazet]

Herbert Xu a écrit :
> On Fri, Nov 13, 2009 at 05:41:21PM +0100, Eric Dumazet wrote:
>> Replying to myself, I found root of the problem and posted a fix.
> 
> Just curious, do you have a link to that fix?
> 

Sure, I thought you were a netdev subscriber, sorry :)

[PATCH net-next-2.6] vlan: Use __vlan_hwaccel_put_tag() in rx

http://patchwork.ozlabs.org/patch/38377/


>> Still the race while updating dev->stats.tx_{bytes|packets} should be addressed eventually...
> 
> Well making it per-napi_struct should do the trick.
> 
> Cheers,

Re: [RFC] vlan: GRO rx statistics

[Eric Dumazet]

Herbert Xu a écrit :
> On Fri, Nov 13, 2009 at 05:41:21PM +0100, Eric Dumazet wrote:
>> Still the race while updating dev->stats.tx_{bytes|packets} should be addressed eventually...
> 
> Well making it per-napi_struct should do the trick.

For normal devices, probably (but many of them use hardware counters anyway)
but not vlan :)

vlan_hwaccel_do_receive() has no napi context.

Re: [RFC] vlan: GRO rx statistics

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 15 Nov 2009 20:35:56 +0100

> vlan_hwaccel_do_receive() has no napi context.

But this is a choice :-)  And being able to split up the RX
counters would be another reason to potentially change that
choice.