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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 21 Sep 2016 10:16:49 +0200
From:   Jesper Dangaard Brouer <>
To:     Tariq Toukan <>
Cc:     Alexei Starovoitov <>,
        Tariq Toukan <>,
        "David S. Miller" <>,,
        Eran Ben Elisha <>,
        Saeed Mahameed <>,
        Rana Shahout <>,
Subject: Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Wed, 21 Sep 2016 10:57:34 +0300
Tariq Toukan <> wrote:

> On 20/09/2016 6:40 PM, Alexei Starovoitov wrote:
> > On Tue, Sep 20, 2016 at 03:53:10PM +0300, Tariq Toukan wrote:  
> >>>>> +	case XDP_ABORTED:  
> >>>> It is not clearly defined, but I believe XDP_ABORTED should also result
> >>>> in a warning (calling bpf_warn_invalid_xdp_action(act)).  
> >> I'll add this.  
> > Certainly NOT.
> > XDP_ABORTED is an exception case when program does divide by zero.
> > It should NOT do bpf_warn. It must drop the packet.
> > We discussed it several months ago.
> > See mlx4/en_rx.c for canonical implementation.
> >  
> This is also the example given here:

Nice, the documentation is already useful :-)))

I actually adjusted the code example after this feedback. Which I also
wrote in this email thread about updating the documentation.  I already
pointed to this commit, but here is a more specific link:

> I prefer to align with the documentation (and with current mlx4 driver 
> code), which means keeping the XDP_ABORTED w/o a warning.
> Anyway, I don't think this should block the coming V2. If you decide to 
> change documentation/specification, we will simply adjust our drivers 
> accordingly.

This is not blocking your V2, please resend so we can all start working
on a common code base for mlx5 (I'm currently running mlx5 with my own
one-page-per-packet patch... and my page_pool on-top)

As discussed in this thread, the outcome will likely be a new interface
for Troubleshooting and Monitoring, as documented and summarized here
so we don't forget:

Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of

Powered by blists - more mailing lists