RE: XDP question - how much can BPF change in xdp_buff?

[Mintz, Yuval]

> BTW, are we considering some offload where the eBPF would return  a set of
> changes [based on some pre-set capabilities set by driver] done on buffer and 
> let
> the HW offload those?
> 
> I understand end goal is eBPF hw-offloading, but seems like there are a lot of
> existing offload facilities that might be leveraged.

On second thought, given that the program is likely to change only a
small set of fields [as opposed to building whole new buffers],
probably fixing the csum isn't going to be much costlier [if at all] then the 
logic
that would be required to determine whether the device would be able to offload
it.

RE: XDP question - how much can BPF change in xdp_buff?

[Mintz, Yuval]

> > So I've [finally] started looking into implementing XDP for qede, and
> > there's one thing I feel like I'm missing in regard to XDP_TX - what's
> > the guarantee/requirement that the bpf program isn't going to
> > transmute some fields of the rx packet in a way that would prevent the
> > forwarding?
> >
> I think there are really two separate questions you're probably asking. 1) Can
> XDP modify a packet in such a way that it won't be forwarded by the driver 
> when
> XDP_TX is returned, ie. driver would drop packet  2) Does anything prevent the
> BPF program from modifying the packet such that it becomes malformed (bad
> checksum, mangled headers, etc.).
> 
> I believe the answer to #1 is "no", the XDP interface assumes raw packets. If
> program returns XDP_TX then the driver will forward the raw packet without any
> further consideration.
> 
> The answer to #2 is "no", there is no check that packet produced is sensible. 
> We
> assume that the user setting the XDP program knows what they are doing.

O.k., thanks - so I can safely assume forwarding wouldn't require any HW 
offloading.

BTW, are we considering some offload where the eBPF would return  a set
of changes [based on some pre-set capabilities set by driver] done on buffer
and let the HW offload those?

I understand end goal is eBPF hw-offloading, but seems like there are a lot of
existing offload facilities that might be leveraged.

Re: XDP question - how much can BPF change in xdp_buff?

[Thomas Graf]

On 10/31/16 at 12:22pm, John Fastabend wrote:
> On 16-10-31 11:57 AM, David Miller wrote:
> > My understanding is that the eBPF program would be responsible
> > for updating the checksum if it mangles the packet in such a
> > way that such a fixup would be required.
> > 
> 
> For XDP we will probably need to add support for at minimum the
> following helpers,
> 
>   bpf_l3_csum_replace
>   bpf_l4_csum_replace
csum_diff

We definitely want some visibility feature that can be enabled for
troubleshooting and debugging which verifies the checksum in SW
after the bpf program is done. Otherwise, if a XDP BPF program
miscalculates the checksum, there is no way to figure it out whether
the checksum is off without attaching another system to capture.

Speaking from experience, getting the checksum right is one of the
time sinks when developing more complex BPF programs.

Re: XDP question - how much can BPF change in xdp_buff?

[Tom Herbert]

On Mon, Oct 31, 2016 at 11:31 AM, Mintz, Yuval  wrote:
> So I've [finally] started looking into implementing XDP
> for qede, and there's one thing I feel like I'm missing in
> regard to XDP_TX - what's the guarantee/requirement
> that the bpf program isn't going to transmute some fields
> of the rx packet in a way that would prevent the forwarding?
>
I think there are really two separate questions you're probably
asking. 1) Can XDP modify a packet in such a way that it won't be
forwarded by the driver when XDP_TX is returned, ie. driver would drop
packet  2) Does anything prevent the BPF program from modifying the
packet such that it becomes malformed (bad checksum, mangled headers,
etc.).

I believe the answer to #1 is "no", the XDP interface assumes raw
packets. If program returns XDP_TX then the driver will forward the
raw packet without any further consideration.

The answer to #2 is "no", there is no check that packet produced is
sensible. We assume that the user setting the XDP program knows what
they are doing.

> E.g., can a BPF change the TCP payload of an incoming packet
> without correcting its TCP checksum, and then expect the
> driver to transmit it [via XDP_TX]? If not, how is this enforced [if at all]?
>
It's not enforced. If program doesn't update a checksum then we assume
that forwarded packet is dropped at the receiver.

> [Looked at samples/bpf/xdp2_kern.c which manipulates the
> UDP header; so I'm not certain what prevents it from doing
> the same when checksum modifications would be required]
>
>
>

Re: XDP question - how much can BPF change in xdp_buff?

[John Fastabend]

On 16-10-31 11:57 AM, David Miller wrote:
> From: "Mintz, Yuval" 
> Date: Mon, 31 Oct 2016 18:31:30 +
> 
>> So I've [finally] started looking into implementing XDP
>> for qede, and there's one thing I feel like I'm missing in
>> regard to XDP_TX - what's the guarantee/requirement
>> that the bpf program isn't going to transmute some fields
>> of the rx packet in a way that would prevent the forwarding?
>>
>> E.g., can a BPF change the TCP payload of an incoming packet
>> without correcting its TCP checksum, and then expect the
>> driver to transmit it [via XDP_TX]? If not, how is this enforced [if at all]?
>>
>> [Looked at samples/bpf/xdp2_kern.c which manipulates the
>> UDP header; so I'm not certain what prevents it from doing
>> the same when checksum modifications would be required]
> 
> My understanding is that the eBPF program would be responsible
> for updating the checksum if it mangles the packet in such a
> way that such a fixup would be required.
> 

For XDP we will probably need to add support for at minimum the
following helpers,

bpf_l3_csum_replace
bpf_l4_csum_replace

Thanks,
John

Re: XDP question - how much can BPF change in xdp_buff?

[David Miller]

From: "Mintz, Yuval" 
Date: Mon, 31 Oct 2016 18:31:30 +

> So I've [finally] started looking into implementing XDP
> for qede, and there's one thing I feel like I'm missing in
> regard to XDP_TX - what's the guarantee/requirement
> that the bpf program isn't going to transmute some fields
> of the rx packet in a way that would prevent the forwarding?
> 
> E.g., can a BPF change the TCP payload of an incoming packet
> without correcting its TCP checksum, and then expect the
> driver to transmit it [via XDP_TX]? If not, how is this enforced [if at all]?
> 
> [Looked at samples/bpf/xdp2_kern.c which manipulates the
> UDP header; so I'm not certain what prevents it from doing
> the same when checksum modifications would be required]

My understanding is that the eBPF program would be responsible
for updating the checksum if it mangles the packet in such a
way that such a fixup would be required.