netdev - Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20160920182717.2de9541e@redhat.com>
Date:   Tue, 20 Sep 2016 18:27:17 +0200
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Tom Herbert <tom@...bertland.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Tariq Toukan <ttoukan.linux@...il.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Eran Ben Elisha <eranbe@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Rana Shahout <ranas@...lanox.com>, brouer@...hat.com
Subject: Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, 20 Sep 2016 09:13:56 -0700
Eric Dumazet <eric.dumazet@...il.com> wrote:

> On Tue, 2016-09-20 at 18:06 +0200, Jesper Dangaard Brouer wrote:
> > On Tue, 20 Sep 2016 08:58:30 -0700
> > Eric Dumazet <eric.dumazet@...il.com> wrote:  
> 
> > > Same for XDP_TX if/when packet is dropped because output ring is full.  
> > 
> > For the XDP_TX case a counter is already incremented[1] but it is a
> > local ring counter (ring->tx_dropped++).
> > 
> > Do you think we should maintain separate counters for XDP? (to have a
> > more consistent interface across drivers...)  
> 
> No, as long as the admin can learn drops are occurring.

Okay, so recording these drops is important for an admin, agreed.  Now
that we have the chance to define the API, wouldn't is be nice if the
admin across drive drivers knew what counter to look for???

> "perf ... -e skb:kfree_skb ..." or drop monitor wont work,
> unfortunately.

That is actually a good idea... why not add a trace point for these
rare drop cases, which is a hassle to debug for an admin?
Let's actually take advantage of all the nice infrastructure the kernel
provides(?)

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