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  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]
Date:   Thu, 10 Sep 2020 12:35:33 -0600
From:   David Ahern <>
To:     Jesper Dangaard Brouer <>,
        Toke Høiland-Jørgensen <>
Cc:     Alexei Starovoitov <>,
        Hangbin Liu <>, bpf <>,
        Network Development <>,
        Jiri Benc <>,
        Eelco Chaudron <>,
        Alexei Starovoitov <>,
        Daniel Borkmann <>,
        Lorenzo Bianconi <>,
        Andrii Nakryiko <>
Subject: Re: [PATCHv11 bpf-next 2/5] xdp: add a new helper for dev map
 multicast support

On 9/10/20 11:50 AM, Jesper Dangaard Brouer wrote:
> Maybe we should change the devmap-prog approach, and run this on the
> xdp_frame's (in bq_xmit_all() to be precise) .  Hangbin's patchset
> clearly shows that we need this "layer" between running the xdp_prog and
> the devmap-prog. 

I would prefer to leave it in dev_map_enqueue.

The main premise at the moment is that the program attached to the
DEVMAP entry is an ACL specific to that dev. If the program is going to
drop the packet, then no sense queueing it.

I also expect a follow on feature will be useful to allow the DEVMAP
program to do another REDIRECT (e.g., potentially after modifying). It
is not handled at the moment as it needs thought - e.g., limiting the
number of iterative redirects. If such a feature does happen, then no
sense queueing it to the current device.

Powered by blists - more mailing lists