On Thu, Mar 21, 2019 at 9:13 AM Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > > On Thu, Mar 21, 2019 at 12:01 PM Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: > > > > On Thu, Mar 21, 2019 at 08:44:33AM -0700, Stanislav Fomichev wrote: > > > > > > If we can agree that we switch everything to xpd-like, do we deprecate the > > > skb-one? > > > > This whole discussion that have been going on for long time is an indication > > that initial bpf flow dissector concept was not thought through > > and I regret on merging it in the first place. > > Adding more hacks on top of it with fake skbs is not going to make it any > > better. > > Since it's been in the official release we cannot remove it now. > > This patch set addresses the only open issue. > > That said, if direction is towards an alternative interface, then it would > make sense for the new interface to supplant the existing one for all > use-cases, even if that existing one cannot be removed. > > Essentially a BPF_PROG_TYPE_FLOW_DISSECTOR_RAW that > takes a simpler context than skb. And either that or a program of > type BPF_PROG_TYPE_FLOW_DISSECTOR can be attached in > skb_flow_dissector_bpf_prog_attach, but not both.
another idea is to keep 'struct __sk_buff' as a context, but have kernel side to be something like struct xdp_buff and disallow access to fields of __sk_buff depending on attach_type. and do different ctx rewrite for __sk_buff->foo depending on attach_type.
