netdev - Re: consistency for statistics with XDP mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 1 Dec 2018 12:14:05 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     David Ahern <dsahern@...il.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "toke@...e.dk" <toke@...e.dk>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "pstaszewski@...are.pl" <pstaszewski@...are.pl>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "jasowang@...hat.com" <jasowang@...hat.com>, brouer@...hat.com
Subject: Re: consistency for statistics with XDP mode

On Fri, 30 Nov 2018 20:41:48 -0800
Jakub Kicinski <jakub.kicinski@...ronome.com> wrote:

> On Fri, 30 Nov 2018 13:35:53 -0700, David Ahern wrote:
> > On 11/30/18 1:30 PM, Michael S. Tsirkin wrote:  
> > >>>> I would like to see basic packets, bytes, and dropped counters
> > >>>> tracked
> > >>>> for Rx and Tx via the standard netdev counters for all devices.     
> > >>
> > >> The problem of reporting XDP_DROP in the netedev drop counter is that
> > >> they don't fit this counter description : "no space in linux buffers"
> > >> and it will be hard for the user to determine whether these drops are
> > >> coming from XDP or because no buffer is available, which will make it
> > >> impossible to estimate packet rate performance without looking at
> > >> ethtool stats.
> > >> And reporting XDP_DROP in the netdev rx packets counter is somehow
> > >> misleading.. since those packets never made it out of this driver.. 
> > >>
> > >>
> > >> And reporting XDP_DROP in the netdev rx packets counter is somehow
> > >> misleading.. since those packets never made it out of this driver..    
> > > 
> > > I think I agree. XDP needs minimal overhead - if user wants to do
> > > counters then user can via maps. And in a sense XDP dropping packet
> > > is much like e.g. TCP dropping packet - it is not counted
> > > against the driver since it's not driver's fault.
> > >     
> > 
> > XDP dropping a packet is completely different.
> > 
> > stats are important. packets disappearing with no counters -- standard
> > counters visible by standard tools -- is a user nightmare. If the
> > agreement is for XDP drops to be in driver level (e.g., xdp_drop) that
> > is fine since it is still retrievable by ethtool -S (existing APIs and
> > existing tools).  
> 
> I don't think that's completely fair.  Disappearing packets are a
> nightmare, but if the user installed a program which silently drops
> packets without incrementing any counter it's their own fault.  If
> cls_bpf returns STOLEN or TRAP, I don't think that's gonna get counted
> anywhere.

Yes, exactly. I think we are all agreeing.

RX packets in the driver NAPI-poll need to be counted as we have always
done in ifconfig stats.  These RX counters are incremented, regardless
of TC/netfilter drop the packet later.  Like wise XDP is a user
installed program, and a user XDP_DROP action/choice should not "hide"
this packet from the drivers RX-counter (as that IMHO could be more
confusing to the user).


> I don't think DPDK drivers maintain "just in case" statistics, either..

I agree. Maintaining counters for everything will cause performance
issues.  That said if we do choose to standardize XDP stats per action,
as most driver do maintain some ethtool counter anyhow, then we have to
make sure this doesn't hurt performance.  One simple trick is to bulk
update these counters at the end of drivers napi_pool function (like
most drivers do for the RX-counter stats).

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer