All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Networking <netdev@vger.kernel.org>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Jiri Benc" <jbenc@redhat.com>,
	"Jesper Dangaard Brouer" <brouer@redhat.com>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>
Subject: Re: [PATCH bpf-next] libbpf: export bpf_object__reuse_map() to libbpf api
Date: Tue, 29 Sep 2020 16:03:45 -0700	[thread overview]
Message-ID: <CAEf4BzZy9=x0neCOdat-CWO4nM3QYgWOKaZpN31Ce5Uz9m_qfg@mail.gmail.com> (raw)
In-Reply-To: <20200929094232.GG2531@dhcp-12-153.nay.redhat.com>

On Tue, Sep 29, 2020 at 2:42 AM Hangbin Liu <liuhangbin@gmail.com> wrote:
>
> On Mon, Sep 28, 2020 at 08:30:42PM -0700, Andrii Nakryiko wrote:
> > > @@ -431,6 +431,7 @@ bpf_map__prev(const struct bpf_map *map, const struct bpf_object *obj);
> > >  /* get/set map FD */
> > >  LIBBPF_API int bpf_map__fd(const struct bpf_map *map);
> > >  LIBBPF_API int bpf_map__reuse_fd(struct bpf_map *map, int fd);
> > > +LIBBPF_API int bpf_object__reuse_map(struct bpf_map *map);
> >
> > It's internal function, which doesn't check that map->pin_path is set,
>
> How about add a path check in bpf_object__reuse_map()?
>
> And off course users who use it should call bpf_map__set_pin_path() first.
>
> > for one thing. It shouldn't be exposed. libbpf exposes
> > bpf_map__set_pin_path() to set pin_path for any map, and then during
> > load time libbpf with "reuse map", if pin_path is not NULL. Doesn't
> > that work for you?
>
> Long story...
>
> When trying to add iproute2 libbpf support that I'm working on. We need to
> create iproute2 legacy map-in-map manually before libbpf load objects, because
> libbpf only support BTF type map-in-map(unless I missed something.).
>
> After creating legacy map-in-map and reuse the fd, if the map has legacy
> pining defined, only set the pin path would not enough as libbpf will skip
> pinning map if map->fd > 0 in bpf_object__create_maps(). See the following
> code bellow.
>
> bpf_map__set_pin_path()
> bpf_create_map_in_map()    <- create inner or outer map
> bpf_map__reuse_fd(map, inner/outer_fd)
> bpf_object__load(obj)
>   - bpf_object__load_xattr()
>     - bpf_object__create_maps()
>       - if (map->fd >= 0)
>           continue      <- this will skip pinning map

so maybe that's the part that needs to be fixed?..

>
> So when handle legacy map-in-map + pin map, we need to create the map
> and pin maps manually at the same time. The code would looks like
> (err handler skipped).
>
> map_fd = bpf_obj_get(pathname);
> if (map_fd > 0) {
>         bpf_map__set_pin_path(map, pathname);
>         return bpf_object__reuse_map(map);   <- here we need the reuse_map
> }
> bpf_create_map_in_map()
> bpf_map__reuse_fd(map, map_fd);
> bpf_map__pin(map, pathname);
>
> So I think this function is needed, what do you think?

I'm still not sure. And to be honest your examples are still a bit too
succinct for me to follow where the problem is exactly. Can you please
elaborate a bit more?

It might very well be that map pinning and FD reuse have buggy and
convoluted logic, but let's try to fix that first, before we expose
new APIs.

>
> Thanks
> Hangbin

  reply	other threads:[~2020-09-29 23:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-29  3:18 [PATCH bpf-next] libbpf: export bpf_object__reuse_map() to libbpf api Hangbin Liu
2020-09-29  3:30 ` Andrii Nakryiko
2020-09-29  9:42   ` Hangbin Liu
2020-09-29 23:03     ` Andrii Nakryiko [this message]
2020-09-30  2:34       ` Hangbin Liu
2020-09-30 18:30         ` Andrii Nakryiko
2020-10-01 11:34           ` Hangbin Liu
2020-10-01 18:17             ` Andrii Nakryiko

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='CAEf4BzZy9=x0neCOdat-CWO4nM3QYgWOKaZpN31Ce5Uz9m_qfg@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=jbenc@redhat.com \
    --cc=liuhangbin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=stephen@networkplumber.org \
    --cc=toke@redhat.com \
    --cc=yhs@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.