On 03/21, Alexei Starovoitov wrote: > 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. That's a great idea! The only problem that in this case, I guess, we need another attach_type and need to ask users explicitly attach to it.
What if we go a bit further: always have xdp_buff-like struct in the kernel? For the real skb it would have data..data_end point to linear packet data (or the first fragment). We would always prohibit access to most __sk_buff fields (like in patch #5 from this series). We'd have to write our own bpf_skb_load_bytes, but that doesn't sound like a big issue.
