On Mon, 26 Aug 2019 19:47:40 +0200
Eric Dumazet <[email protected]> wrote:
> On 8/26/19 4:07 PM, Shmulik Ladkani wrote:
> > - ipv4 forwarding to dummy1, where eBPF nat4-to-6 program is attached
> > at TC Egress (calls 'bpf_skb_change_proto()'), then redirect to ingress
> > on same device.
> > NOTE: 'bpf_skb_proto_4_to_6()' mangles 'shinfo->gso_size'
>
> Doing this on an skb with a frag_list is doomed, in current gso_segment()
> state.
>
> A rewrite would be needed (I believe I did so at some point, but Herbert Xu
> fought hard against it)
Thanks Eric,
- If a rewrite is still considered out of the question, how can one use
eBPF's bpf_skb_change_proto() safely without disabling GRO completely?
- e.g. is there a way to force the GROed skbs to fit into a layout that is
tolerated by skb_segment?
- alternatively can eBPF layer somehow enforce segmentation of the
original GROed skb before mangling the gso_size?
- Another thing that puzzles me is that we hit the BUG_ON rather rarely
and cannot yet reproduce synthetically. If skb_segment's handling of
skbs with a frag_list (that have gso_size mangled) is broken, I'd expect
to hit this more often... Any ideas?
- Suppose going for a rewrite, care to elaborate what's exactly missing
in skb_segment's logic?
I must admit I do not fully understand all the different code flows in
this function, it seems to support many different input skbs - any
assistance is highly appreciated.
Shmulik
