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
> i
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 N
On Tue, 20 Sep 2016 09:45:28 -0700
Alexei Starovoitov wrote:
> To your other question:
> > Please explain why a eBPF program error (div by zero) must be a silent
> > drop?
>
> because 'div by zero' is an abnormal situation that shouldn't be exploited.
> Meaning if xdp program is doing DoS pre
On Tue, 20 Sep 2016 20:59:39 +0200 Jesper Dangaard Brouer
wrote:
> On Tue, 20 Sep 2016 10:39:20 -0700 Eric Dumazet
> wrote:
>
[...]
>
> > Many existing supervision infrastructures collect device snmp
> > counters, and run as unprivileged programs.
>
> A supervision infrastructures is a
On Tue, Sep 20, 2016 at 11:59 AM, Jesper Dangaard Brouer
wrote:
> On Tue, 20 Sep 2016 10:39:20 -0700
> Eric Dumazet wrote:
>
>> On Tue, 2016-09-20 at 09:45 -0700, Alexei Starovoitov wrote:
>>
>> > because 'div by zero' is an abnormal situation that shouldn't be exploited.
>> > Meaning if xdp prog
On Tue, 20 Sep 2016 10:39:20 -0700
Eric Dumazet wrote:
> On Tue, 2016-09-20 at 09:45 -0700, Alexei Starovoitov wrote:
>
> > because 'div by zero' is an abnormal situation that shouldn't be exploited.
> > Meaning if xdp program is doing DoS prevention and it has a bug that
> > attacker can now ex
On Tue, 2016-09-20 at 09:45 -0700, Alexei Starovoitov wrote:
> because 'div by zero' is an abnormal situation that shouldn't be exploited.
> Meaning if xdp program is doing DoS prevention and it has a bug that
> attacker can now exploit by sending a crafted packet that causes
> 'div by zero' and k
On 09/20/16 at 09:45am, Alexei Starovoitov wrote:
> that's a great idea. Instead of adding aborted, ring_full, blahblah counters
> everywhere that cost performance, let's add tracepoints that are nops
> when not in use.
> And if all drivers call the same tracepoints it will be even better.
> Monito
On Tue, Sep 20, 2016 at 06:27:17PM +0200, Jesper Dangaard Brouer wrote:
> On Tue, 20 Sep 2016 09:13:56 -0700
> Eric Dumazet 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 wrote:
> >
> > > > Same for XDP
On Tue, 20 Sep 2016 09:13:56 -0700
Eric Dumazet 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 wrote:
>
> > > Same for XDP_TX if/when packet is dropped because output ring is full.
> >
> > For the XDP_TX cas
On Tue, 2016-09-20 at 18:06 +0200, Jesper Dangaard Brouer wrote:
> On Tue, 20 Sep 2016 08:58:30 -0700
> Eric Dumazet 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 (rin
On Tue, 20 Sep 2016 08:58:30 -0700
Eric Dumazet wrote:
> On Tue, 2016-09-20 at 08:51 -0700, Tom Herbert wrote:
> > On Tue, Sep 20, 2016 at 8:40 AM, Alexei Starovoitov
> > wrote:
> > > On Tue, Sep 20, 2016 at 03:53:10PM +0300, Tariq Toukan wrote:
> > >> >>>+ case XDP_ABORTED:
> > >> >>It i
On Tue, 20 Sep 2016 08:40:37 -0700
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(ac
On Tue, Sep 20, 2016 at 08:51:05AM -0700, Tom Herbert wrote:
> On Tue, Sep 20, 2016 at 8:40 AM, 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
On Tue, 2016-09-20 at 08:51 -0700, Tom Herbert wrote:
> On Tue, Sep 20, 2016 at 8:40 AM, 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
> >> >>
On Tue, Sep 20, 2016 at 8:40 AM, 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 a
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 pro
On 20/09/2016 2:33 PM, Jesper Dangaard Brouer wrote:
Resending, email didn't reach the list (used wrong sender email)
On Tue, 20 Sep 2016 10:29:43 +0200 Jesper Dangaard Brouer
wrote:
On Mon, 19 Sep 2016 16:58:58 +0300 Tariq Toukan wrote:
+ act = bpf_prog_run_xdp(prog, &xdp);
+
Resending, email didn't reach the list (used wrong sender email)
On Tue, 20 Sep 2016 10:29:43 +0200 Jesper Dangaard Brouer
wrote:
> On Mon, 19 Sep 2016 16:58:58 +0300 Tariq Toukan wrote:
>
> > + act = bpf_prog_run_xdp(prog, &xdp);
> > + switch (act) {
> > + case XDP_PASS:
> > +
On Mon, 19 Sep 2016 16:58:58 +0300 Tariq Toukan wrote:
> + act = bpf_prog_run_xdp(prog, &xdp);
> + switch (act) {
> + case XDP_PASS:
> + return false;
> + case XDP_TX:
> + consumed = mlx5e_xmit_xdp_frame(&rq->channel->xdp_sq, di,
> +
From: Saeed Mahameed
Adding support for XDP_TX forwarding from xdp program.
Using XDP, now user can loop packets out of the same port.
We create a dedicated TX SQ for each channel that will serve
XDP programs that return XDP_TX action to loop packets back to
the wire directly from the channel RQ
21 matches
Mail list logo
