All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Andrey Ignatov <rdna@fb.com>
Cc: <alexei.starovoitov@gmail.com>, <daniel@iogearbox.net>,
	<oss-drivers@netronome.com>, <netdev@vger.kernel.org>
Subject: Re: [PATCH bpf-next v3 12/13] tools: libbpf: allow map reuse
Date: Tue, 10 Jul 2018 21:53:52 -0700	[thread overview]
Message-ID: <20180710215352.600270b5@cakuba.lan> (raw)
In-Reply-To: <20180711034535.GC52033@rdna-mbp>

On Tue, 10 Jul 2018 20:45:36 -0700, Andrey Ignatov wrote:
> Acked-by: Andrey Ignatov <rdna@fb.com>

Thank you! :)
 
> Thanks for all the changes Jakub! Sorry, it forced you to deal with
> strerror_r().

No worries, I already had issues with reallocarray().  Because we have
two reasons now the split seems more justified, and it's cleaner IMHO.

> One thing, I'm not really sure, is if there is a reason not to copy
> ifindex as well from the map that corresponds to passed fd. It's fine
> with me to follow-up separately though if it's needed.

To handle the ifindex correctly we would have to deal with net
namespaces.  Note that ifindex comes with the pair of netns_* fields
in bpf_map_info.  Netdev can also be moved to another namespace after
the information is cached in libbpf.

Right now there is no use for ifindex other than to populate the
attribute at creation time (where it always refer to current namespace).
I'd rather keep ifindex as a input only parameter until we have a clear
use for reading it, otherwise we have to decide on the semantics in the
dark and may bring in quite a bit of complexity for no good reason.

  reply	other threads:[~2018-07-11  4:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-10 21:42 [PATCH bpf-next v3 00/13] tools: bpf: extend bpftool prog load Jakub Kicinski
2018-07-10 21:42 ` [PATCH bpf-next v3 01/13] selftests/bpf: remove duplicated word from test offloads Jakub Kicinski
2018-07-10 21:42 ` [PATCH bpf-next v3 02/13] selftests/bpf: add Error: prefix in check_extack helper Jakub Kicinski
2018-07-10 21:42 ` [PATCH bpf-next v3 03/13] tools: bpftool: refactor argument parsing for prog load Jakub Kicinski
2018-07-10 21:42 ` [PATCH bpf-next v3 04/13] tools: bpftool: add support for loading programs for offload Jakub Kicinski
2018-07-10 21:42 ` [PATCH bpf-next v3 05/13] tools: libbpf: expose the prog type guessing from section name logic Jakub Kicinski
2018-07-11  3:01   ` Andrey Ignatov
2018-07-10 21:43 ` [PATCH bpf-next v3 06/13] tools: bpftool: allow users to specify program type for prog load Jakub Kicinski
2018-07-10 21:43 ` [PATCH bpf-next v3 07/13] tools: libbpf: recognize offload neutral maps Jakub Kicinski
2018-07-10 21:43 ` [PATCH bpf-next v3 08/13] tools: libbpf: add extended attributes version of bpf_object__open() Jakub Kicinski
2018-07-11  3:03   ` Andrey Ignatov
2018-07-10 21:43 ` [PATCH bpf-next v3 09/13] tools: bpftool: reimplement bpf_prog_load() for prog load Jakub Kicinski
2018-07-10 21:43 ` [PATCH bpf-next v3 10/13] tools: libbpf: move library error code into a separate file Jakub Kicinski
2018-07-10 21:43 ` [PATCH bpf-next v3 11/13] tools: bpf: make use of reallocarray Jakub Kicinski
2018-07-13 23:53   ` [bpf-next,v3,11/13] " Guenter Roeck
2018-07-14  0:07     ` Jakub Kicinski
2018-07-14  0:31       ` Guenter Roeck
2018-07-14  1:16         ` Jakub Kicinski
2018-07-10 21:43 ` [PATCH bpf-next v3 12/13] tools: libbpf: allow map reuse Jakub Kicinski
2018-07-11  3:45   ` Andrey Ignatov
2018-07-11  4:53     ` Jakub Kicinski [this message]
2018-07-10 21:43 ` [PATCH bpf-next v3 13/13] tools: bpftool: allow reuse of maps with bpftool prog load Jakub Kicinski
2018-07-11 20:18 ` [PATCH bpf-next v3 00/13] tools: bpf: extend " 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=20180710215352.600270b5@cakuba.lan \
    --to=jakub.kicinski@netronome.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    --cc=rdna@fb.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.