On Thu, Aug 25, 2016 at 9:09 AM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, Mahesh. > > On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote: >> In short most of the associated problems are handled by the >> cgroup-infra / APIs while all that need separate solution in >> alternatives. Tejun, feels like I'm advocating cgroup approach to you >> ;) > > My concern here is that the proposed fixed mechanism isn't gonna be > enough. Port range matching wouldn't scale, so we'd need some hashmap > style thing which may be too expensive for simple matches so either we > do something adaptive or have different interfaces for the two and so > on. IOW, I think this approach is likely to replicate what iptables > have been doing with its extensions. I don't doubt that it is one of > the workable approaches but hardly an attractive one especially at > this point. > > ebpf approach does have its shortcomings for sure but mending them > seems a lot more manageable and future-proof than going with fixed but > constantly expanding set of operations. e.g. We can add per-cgroup > bpf programs which are called only on socket creation or other major > events, or just let bpf programs which get called on bind(2), and add > some per-cgroup state variables which are maintained by cgroup code > which can be used from these bpf programs. > Well, I haven't seen any of these yet (please point me the right place if I missed) Especially the hooks that allows users to add per-cgroup bpf programs that can be used in control-path (I think Daniel's recent patches allow in data-path). > Thanks. > > -- > tejun -- 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
