netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 01:19:01 +0200	[thread overview]
Message-ID: <594C5065.2010900@iogearbox.net> (raw)
In-Reply-To: <B03E3B5A-50E2-4291-B091-23927AF6846F@fb.com>

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

  reply	other threads:[~2017-06-22 23:19 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 [this message]
2017-06-22 23:57         ` Lawrence Brakmo
2017-06-23 21:15           ` Daniel Borkmann
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=594C5065.2010900@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).