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. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
