On Wed, Sep 14, 2016 at 01:42:49PM +0200, Daniel Borkmann wrote: > >As I said, I'm open to discussing that. In order to make it work for L3, > >the LL_OFF issues need to be solved, as Daniel explained. Daniel, > >Alexei, any idea how much work that would be? > > Not much. You simply need to declare your own struct bpf_verifier_ops > with a get_func_proto() handler that handles BPF_FUNC_skb_load_bytes, > and verifier in do_check() loop would need to handle that these ld_abs/ > ld_ind are rejected for BPF_PROG_TYPE_CGROUP_SOCKET. yep. that part is solvable. I'm still torn between l2 and l3. On one side it sux to lose l2 information. yet we don't have a use case to look into l2 for our container monitoring, so the only thing lack of l2 will do is confuse byte accounting, since instead of skb->len, we'd need to do skb->len + ETH_HLEN... but I guess vlan handling messes it up as well. On the other side doing it at socket level we can drop these checks: + if (!sk || !sk_fullsock(sk)) + return 0; + + if (sk->sk_family != AF_INET && + sk->sk_family != AF_INET6) + return 0; which will make it even faster when it's on. So I don't mind either l2 and l3. I guess if l3 approach will prove to be limiting, we can add l2 later? -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
