On Fri, 6 Nov 2020 09:27:45 +0100 Heiner Kallweit wrote: > On 06.11.2020 08:48, Heiner Kallweit wrote: > > On 06.11.2020 02:14, Jakub Kicinski wrote: > >> On Wed, 4 Nov 2020 15:25:24 +0100 Heiner Kallweit wrote: > >>> @@ -1066,7 +1054,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff > >>> *skb, struct net_device *dev) > >>> return NETDEV_TX_OK; > >>> > >>> drop: > >>> - this_cpu_inc(tun->pcpu_stats->tx_dropped); > >>> + dev->stats.tx_dropped++; > >>> skb_tx_error(skb); > >>> kfree_skb(skb); > >>> rcu_read_unlock(); > >> > >> This is no longer atomic. Multiple CPUs may try to update it at the > >> same time. > >> > >> Do you know what the story on dev->rx_dropped is? The kdoc says drivers > >> are not supposed to use it but: > >> > >> drivers/net/ipvlan/ipvlan_core.c: > >> atomic_long_inc(&skb->dev->rx_dropped); > >> drivers/net/macvlan.c: atomic_long_inc(&skb->dev->rx_dropped); > >> drivers/net/vxlan.c: atomic_long_inc(&vxlan->dev->rx_dropped); > >> > >> Maybe tun can use it, too? > >> > > Thanks, yes that should be possible. Here we speak about tx_dropped, > > but AFAICS the same applies as for rx_dropped. Will change it accordingly > > in a v3. > > > For rx_dropped and tx_dropped it's easy, however tun also has a per-cpu > counter for rx_frame_errors that is incremented if virtio_net_hdr_to_skb() > fails. Not sure how to deal best with this one.
Umpf, yeah, so I'd probably add an atomic long to struct tun_struct, but then you'll need to keep the ndo implementation instead of using dev_get_tstats64 directly. I can't think of a better way, tho.
