On 8/20/20, David Miller wrote:
> From: "Jason A. Donenfeld"
> Date: Thu, 20 Aug 2020 11:13:49 +0200
>
>> It seems like if an eBPF program pushes on a VLAN tag or changes the
>> protocol or does any other modification, it will be treated in exactly
>> the same way as the L2 packet above by the re
From: "Jason A. Donenfeld"
Date: Thu, 20 Aug 2020 11:13:49 +0200
> It seems like if an eBPF program pushes on a VLAN tag or changes the
> protocol or does any other modification, it will be treated in exactly
> the same way as the L2 packet above by the remaining parts of the
> networking stack.
On Thu, Aug 20, 2020 at 1:22 AM David Miller wrote:
>
> From: "Jason A. Donenfeld"
> Date: Sat, 15 Aug 2020 09:41:02 +0200
>
> > A user reported that packets from wireguard were possibly ignored by XDP
> > [1]. Another user reported that modifying packets from layer 3
> > interfaces results in im
From: "Jason A. Donenfeld"
Date: Sat, 15 Aug 2020 09:41:02 +0200
> A user reported that packets from wireguard were possibly ignored by XDP
> [1]. Another user reported that modifying packets from layer 3
> interfaces results in impossible to diagnose drops.
Jason this really is a minefield.
If
On Sat, 15 Aug 2020 09:41:02 +0200
"Jason A. Donenfeld" wrote:
> A user reported that packets from wireguard were possibly ignored by XDP
> [1]. Another user reported that modifying packets from layer 3
> interfaces results in impossible to diagnose drops.
>
> Apparently, the generic skb xdp han
A user reported that packets from wireguard were possibly ignored by XDP
[1]. Another user reported that modifying packets from layer 3
interfaces results in impossible to diagnose drops.
Apparently, the generic skb xdp handler path seems to assume that
packets will always have an ethernet header,
