All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Colascione <dancol@google.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Joel Fernandes <joelaf@google.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Tim Murray <timmurray@google.com>,
	netdev <netdev@vger.kernel.org>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Lorenzo Colitti <lorenzo@google.com>,
	Chenbo Feng <fengc@google.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Alexei Starovoitov <ast@fb.com>
Subject: Re: [PATCH v3] Add BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES bpf(2) command
Date: Mon, 30 Jul 2018 03:25:43 -0700	[thread overview]
Message-ID: <CAKOZuesH_LRdt15aXaRQRPSNzN-URTQWgSgr0zLsv8ZKFU9=9Q@mail.gmail.com> (raw)
In-Reply-To: <e8f6e709-e694-ddad-b61e-d2ce1598dff3@iogearbox.net>

On Mon, Jul 30, 2018 at 3:04 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> Hmm, I don't think such UAPI as above is future-proof. In case we would want
> a similar mechanism in future for other maps, we would need a whole new bpf
> command or reuse BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES as a workaround though
> the underlying map may not even be a map-to-map. Additionally, we don't have
> any map object at hand in the above, so we couldn't make any finer grained
> decisions either. Something like below would be more suitable and leaves room
> for extending this further in future.

YAGNI. Your proposed mechanism doesn't add anything under the current
implementation. It's also not clear how a map-specific synchronization
command is supposed to work in cases where we swap multiple map
references. Do we synchronize_rcu multiple times? Why would we impose
that inefficiency just for the sake of some non-specific future
extensibility? Add some kind of batching layer? The current approach
works for the anticipated use cases.

While my preference is not to talk about map-to-maps at all in the
user API and instead spec the thing as talking about map references in
general, I'd rather have something that talks about
references-to-maps-acquired-from-maps than this interface.

  reply	other threads:[~2018-07-30 10:25 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-29 15:51 [PATCH v2] Add BPF_SYNCHRONIZE_MAPS bpf(2) command Alexei Starovoitov
2018-07-29 20:46 ` Daniel Colascione
2018-07-29 20:58   ` [PATCH v3] Add BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES " Daniel Colascione
2018-07-30 10:04     ` Daniel Borkmann
2018-07-30 10:04       ` Daniel Borkmann
2018-07-30 10:25       ` Daniel Colascione [this message]
2018-07-31  0:26         ` Jakub Kicinski
2018-07-31  0:33           ` Daniel Colascione
2018-07-31  0:45             ` Jakub Kicinski
2018-07-31  0:50               ` Daniel Colascione
2018-07-31  1:14                 ` Jakub Kicinski
2018-07-31  8:34             ` Daniel Borkmann
2018-07-31  9:36               ` Daniel Colascione
2018-08-10 22:52                 ` Alexei Starovoitov
2018-08-14 20:37                   ` Daniel Colascione
2018-08-16  4:01                     ` Alexei Starovoitov
2018-10-12 10:54                       ` [PATCH v4] Wait for running BPF programs when updating map-in-map Daniel Colascione
2018-10-12 20:54                         ` Joel Fernandes
2018-10-13  2:31                         ` Alexei Starovoitov
2018-10-16 17:39                           ` Joel Fernandes
2018-10-18 15:46                             ` Alexei Starovoitov
2018-10-18 23:36                               ` Joel Fernandes
2018-11-10  2:01                                 ` Chenbo Feng
2018-11-10 15:22                                   ` Greg KH
2018-11-10 18:58                                     ` Chenbo Feng
     [not found]     ` <CAKOZues6SE_c=ix7ap6QaJHqd1TmYpWWMJiu3=TtuqgKuqOUCA@mail.gmail.com>
2018-08-10 22:29       ` [PATCH v3] Add BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES bpf(2) command Alexei Starovoitov
2018-07-31  2:01 ` [PATCH v2] Add BPF_SYNCHRONIZE_MAPS " Joel Fernandes
2018-07-31  2:06   ` Joel Fernandes
2018-07-31  4:03     ` Y Song
2018-07-31 21:56       ` Joel Fernandes
2018-07-31 22:30         ` Daniel Borkmann

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='CAKOZuesH_LRdt15aXaRQRPSNzN-URTQWgSgr0zLsv8ZKFU9=9Q@mail.gmail.com' \
    --to=dancol@google.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@fb.com \
    --cc=daniel@iogearbox.net \
    --cc=fengc@google.com \
    --cc=joelaf@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo@google.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=netdev@vger.kernel.org \
    --cc=timmurray@google.com \
    /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.