On 09/22/2016 05:12 PM, Daniel Borkmann wrote: > On 09/22/2016 02:05 PM, Pablo Neira Ayuso wrote: >> Benefits are, rewording previous email: >> >> * You get access to all of the existing netfilter hooks in one go >> to run bpf programs. No need for specific redundant hooks. This >> provides raw access to the netfilter hook, you define the little >> code that your hook runs before you bpf run invocation. So there >> is *no need to bloat the stack with more hooks, we use what we >> have.* > > But also this doesn't really address the fundamental underlying problem > that is discussed here. nft doesn't even have cgroups v2 support, only > xt_cgroups has it so far, but even if it would have it, then it's still > a scalability issue that this model has over what is being proposed by > Daniel, since you still need to test linearly wrt cgroups v2 membership, > whereas in the set that is proposed it's integral part of cgroups and can > be extended further, also for non-networking users to use this facility. > Or would the idea be that the current netfilter hooks would be redone in > a way that they are generic enough so that any other user could make use > of it independent of netfilter? Yes, that part I don't understand either. Pablo, could you outline in more detail (in terms of syscalls, commands, resulting nftables layout etc) how your proposed model would support having per-cgroup byte and packet counters for both ingress and egress, and filtering at least for ingress? And how would that mitigate the race gaps you have been worried about, between cgroup creation and filters taking effect for a task? Thanks, Daniel -- 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
