vlan: GRO rx statistics
Subsystems (2)
RFC 1/1 vlan: GRO rx statistics
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 ?
net/8021q/vlan_core.c +5 -0
@@ -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(
Quoted 17 lines · 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 ?
net/8021q/vlan_core.c +0
-0@@ -89,6 +89,11 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,if (!skb->dev)
net/8021q/vlan_core.c vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp, · line 99
Quoted 10 lines
net/8021q/vlan_core.c +5
-0goto 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...
Quoted 1 line · Eric Dumazet
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.
Quoted 2 lines · Eric Dumazet
Replying to myself, I found root of the problem and posted a fix.
Just curious, do you have a link to that fix?
Quoted 1 line
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,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtQuoted 5 lines · Herbert Xu
Quoted 1 line · Eric Dumazet
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/
Quoted 5 lines
Quoted 1 line
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,
Quoted 4 lines · Herbert Xu
Quoted 1 line · Eric Dumazet
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.
David Miller
maintainerFrom: Eric Dumazet <[email protected]>
Date: Sun, 15 Nov 2009 20:35:56 +0100
Quoted 1 line
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.