From: Daniel Borkmann <daniel@iogearbox.net>
To: Lawrence Brakmo <brakmo@fb.com>, netdev <netdev@vger.kernel.org>
Cc: Kernel Team <Kernel-team@fb.com>, Blake Matheny <bmatheny@fb.com>,
Alexei Starovoitov <ast@fb.com>,
David Ahern <dsa@cumulusnetworks.com>
Subject: Re: [PATCH net-next v3 01/15] bpf: BPF support for sock_ops
Date: Fri, 23 Jun 2017 23:15:22 +0200 [thread overview]
Message-ID: <594D84EA.5080203@iogearbox.net> (raw)
In-Reply-To: <82AC8CB1-F770-4EFA-9223-E2C94626582F@fb.com>
On 06/23/2017 01:57 AM, Lawrence Brakmo wrote:
> On 6/22/17, 4:19 PM, "netdev-owner@vger.kernel.org on behalf of Daniel Borkmann" <netdev-owner@vger.kernel.org on behalf of daniel@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
Otoh, major distros are highly likely to enable this on by default anyway.
> 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.
But then you would need to go through two program passes for setting
such parameters? Other option could be to make the per cgroup ops more
fine grained and use the effective one that was inherited for delegating
to default ops. My gut feeling is just that this makes interactions to
manage this and enforcement in combination with the later planned per
cgroups ops more complex if the same use-case could indeed be resolved
with per cgroups only.
> 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
next prev parent reply other threads:[~2017-06-23 21:15 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-20 3:00 PATCH net-next v3 00/15 Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 01/15] bpf: BPF support for sock_ops Lawrence Brakmo
2017-06-22 22:41 ` Daniel Borkmann
2017-06-22 22:58 ` Lawrence Brakmo
2017-06-22 23:19 ` Daniel Borkmann
2017-06-22 23:57 ` Lawrence Brakmo
2017-06-23 21:15 ` Daniel Borkmann [this message]
2017-06-28 17:45 ` Lawrence Brakmo
2017-06-29 9:47 ` Daniel Borkmann
2017-06-20 3:00 ` [PATCH net-next v3 02/15] bpf: program to load sock_ops BPF programs Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 03/15] bpf: Support for per connection SYN/SYN-ACK RTOs Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 04/15] bpf: Sample bpf program to set " Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 05/15] bpf: Support for setting initial receive window Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 06/15] bpf: Sample bpf program to set initial window Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 07/15] bpf: Add setsockopt helper function to bpf Lawrence Brakmo
2017-06-20 21:25 ` Craig Gallek
2017-06-21 16:51 ` Lawrence Brakmo
2017-06-21 17:13 ` Craig Gallek
2017-06-21 23:55 ` Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 08/15] bpf: Add TCP connection BPF callbacks Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 09/15] bpf: Sample BPF program to set buffer sizes Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 10/15] bpf: Add support for changing congestion control Lawrence Brakmo
2017-06-20 8:40 ` kbuild test robot
2017-06-20 3:00 ` [PATCH net-next v3 11/15] bpf: Sample BPF program to set " Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 12/15] bpf: Adds support for setting initial cwnd Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 13/15] bpf: Sample BPF program to set " Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 14/15] bpf: Adds support for setting sndcwnd clamp Lawrence Brakmo
2017-06-20 3:00 ` [PATCH net-next v3 15/15] bpf: Sample bpf program to set " Lawrence Brakmo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=594D84EA.5080203@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=Kernel-team@fb.com \
--cc=ast@fb.com \
--cc=bmatheny@fb.com \
--cc=brakmo@fb.com \
--cc=dsa@cumulusnetworks.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.