On Wed, Nov 21, 2018 at 10:48:21AM -0800, Vlad Dumitrescu wrote: > On Wed, Nov 21, 2018 at 5:08 AM Eric Dumazet <[email protected]> wrote: > > > > > > > > On 11/20/2018 06:40 PM, Alexei Starovoitov wrote: > > > > > > > > looks good to me. > > > > > > Any particular reason you decided to disable it for cg_skb ? > > > It seems to me the same EDT approach will work from > > > cgroup-bpf skb hooks just as well and then we can have neat > > > way of controlling traffic per-container instead of tc-clsbpf global. > > > If you're already on cgroup v2 it will save you a lot of classifier > > > cycles, since you'd be able to group apps by cgroup > > > instead of relying on ip only. > > > > Vlad first wrote a complete version, but we felt explaining the _why_ > > was probably harder. > > > > No particular reason, other than having to write more tests perhaps. > > This sounds reasonable to me. I can prepare a v2.
thank you > Any concerns regarding capabilities? For example data and data_end are > only available to CAP_SYS_ADMIN. Note that enforcement of this would > be done by a global component later in the pipeline (e.g., FQ qdisc). I'd do cap_sys_admin for now, since i'm not sure whether any tstamp values will be acceptable to fq. > Any opinions on sk_filter, lwt, and sk_skb before I send v2? sk_filter not appealing, since it's too late in the stack. lwt could be interesting, but I'd wait until first user appears. sk_skb - useful, but it requires more work. We'll follow up to that sk_skb with our own patches. Thanks!
