On 6/22/17, 4:19 PM, "netdev-ow...@vger.kernel.org on behalf of Daniel
Borkmann" <netdev-ow...@vger.kernel.org on behalf of dan...@iogearbox.net>
wrote:
On 06/23/2017 12:58 AM, Lawrence Brakmo wrote:
[...]
> Daniel, I see value for having a global program, so I would like to keep
that. When
> this patchset is accepted, I will submit one that adds support for per
cgroup
> sock_ops programs, with the option to use the global one if none is
> specified for a cgroup. We could also have the option of the cgroup
sock_ops
> program choosing if the global program should run for a particular op
based on
> its return value. We can iron it out the details when that patch is
submitted.
Hm, could you elaborate on the value part compared to per cgroups ops?
My understanding is that per cgroup would already be a proper superset
of just the global one anyway, so why not going with that in the first
place since you're working on it?
What would be the additional value? How would global vs per cgroup one
interact with each other in terms of enforcement e.g., there's already
semantics in place for cgroups descendants, would it be that we set
TCP parameters twice or would you disable the global one altogether?
Just wondering as you could avoid these altogether with going via cgroups
initially.
Thanks,
Daniel
Well, for starters the global program will work even if CONFIG_CGROUP_BPF is
not defined. It is also an easier concept for when a global program is all that
is required. But I also had in mind that behaviors that were in common for
most cgroup programs could be handled by the global program instead of
adding it to all cgroup programs. In this scenario the global program
represents the default behavior that can be override by the cgroup
program (per op). For example, the cgroup program could return a value
to indicate that that op should be passed to the global program.
I agree 100% with you on the value of cgroup programs, but I just happen
to think there is also value in the global program.
Thanks,
Lawrence
