All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: brouer@redhat.com, netdev@vger.kernel.org
Subject: Re: [PATCH bpf-next 05/11] bpf: avoid retpoline for lookup/update/delete calls on maps
Date: Tue, 29 May 2018 19:23:24 +0200	[thread overview]
Message-ID: <20180529192324.7a1db7ee@redhat.com> (raw)
In-Reply-To: <20180528004344.3606-6-daniel@iogearbox.net>

On Mon, 28 May 2018 02:43:38 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:

> While some of the BPF map lookup helpers provide a ->map_gen_lookup()
> callback for inlining the map lookup altogether it is not available
> for every map, so the remaining ones have to call bpf_map_lookup_elem()
> helper which does a dispatch to map->ops->map_lookup_elem(). In
> times of retpolines, this will control and trap speculative execution
> rather than letting it do its work for the indirect call and will
> therefore cause a slowdown. Likewise, bpf_map_update_elem() and
> bpf_map_delete_elem() do not have an inlined version and need to call
> into their map->ops->map_update_elem() resp. map->ops->map_delete_elem()
> handlers.
> 
> Before:
> 
>   # bpftool p d x i 1

I would really appreciate if we can use the long options in these kind
of examples.  It makes the command "self-documenting" and searchable by
google.

Here it would be:

 # bpftool prog dump xlated id 1

>     0: (bf) r2 = r10
>     1: (07) r2 += -8
>     2: (7a) *(u64 *)(r2 +0) = 0
>     3: (18) r1 = map[id:1]
>     5: (85) call __htab_map_lookup_elem#232656
>     6: (15) if r0 == 0x0 goto pc+4
>     7: (71) r1 = *(u8 *)(r0 +35)
>     8: (55) if r1 != 0x0 goto pc+1
>     9: (72) *(u8 *)(r0 +35) = 1
>    10: (07) r0 += 56
>    11: (15) if r0 == 0x0 goto pc+4
>    12: (bf) r2 = r0
>    13: (18) r1 = map[id:1]
>    15: (85) call bpf_map_delete_elem#215008  <-- indirect call via
>    16: (95) exit                                 helper
> 
> After:
> 
>   # bpftool p d x i 1

Same here

>     0: (bf) r2 = r10
>     1: (07) r2 += -8
>     2: (7a) *(u64 *)(r2 +0) = 0
>     3: (18) r1 = map[id:1]
>     5: (85) call __htab_map_lookup_elem#233328
>     6: (15) if r0 == 0x0 goto pc+4
>     7: (71) r1 = *(u8 *)(r0 +35)
>     8: (55) if r1 != 0x0 goto pc+1
>     9: (72) *(u8 *)(r0 +35) = 1
>    10: (07) r0 += 56
>    11: (15) if r0 == 0x0 goto pc+4
>    12: (bf) r2 = r0
>    13: (18) r1 = map[id:1]
>    15: (85) call htab_lru_map_delete_elem#238240  <-- direct call
>    16: (95) exit
> 


-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

  reply	other threads:[~2018-05-29 17:23 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-28  0:43 [PATCH bpf-next 00/11] Misc BPF improvements Daniel Borkmann
2018-05-28  0:43 ` [PATCH bpf-next 01/11] bpf: test case for map pointer poison with calls/branches Daniel Borkmann
2018-05-29 18:01   ` Song Liu
2018-05-28  0:43 ` [PATCH bpf-next 02/11] bpf: add also cbpf long jump test cases with heavy expansion Daniel Borkmann
2018-05-29 18:09   ` Song Liu
2018-05-28  0:43 ` [PATCH bpf-next 03/11] bpf: fixup error message from gpl helpers on license mismatch Daniel Borkmann
2018-05-29 17:16   ` Jesper Dangaard Brouer
2018-05-29 18:10     ` Song Liu
2018-05-28  0:43 ` [PATCH bpf-next 04/11] bpf: show prog and map id in fdinfo Daniel Borkmann
2018-05-29 17:27   ` Jesper Dangaard Brouer
2018-05-29 19:55     ` Daniel Borkmann
2018-05-30 16:15       ` Song Liu
2018-05-30 17:15         ` Jesper Dangaard Brouer
2018-05-28  0:43 ` [PATCH bpf-next 05/11] bpf: avoid retpoline for lookup/update/delete calls on maps Daniel Borkmann
2018-05-29 17:23   ` Jesper Dangaard Brouer [this message]
2018-05-30 17:06   ` Song Liu
2018-05-28  0:43 ` [PATCH bpf-next 06/11] bpf: add bpf_skb_cgroup_id helper Daniel Borkmann
2018-05-29 12:15   ` Quentin Monnet
2018-05-29 15:43     ` Daniel Borkmann
2018-05-28  0:43 ` [PATCH bpf-next 07/11] bpf: make sure to clear unused fields in tunnel/xfrm state fetch Daniel Borkmann
2018-05-30 17:15   ` Song Liu
2018-05-28  0:43 ` [PATCH bpf-next 08/11] bpf: fix cbpf parser bug for octal numbers Daniel Borkmann
2018-05-30 17:16   ` Song Liu
2018-05-28  0:43 ` [PATCH bpf-next 09/11] bpf: fix context access in tracing progs on 32 bit archs Daniel Borkmann
2018-05-30 16:46   ` Song Liu
2018-05-28  0:43 ` [PATCH bpf-next 10/11] bpf: sync bpf uapi header with tools Daniel Borkmann
2018-05-30 16:10   ` Song Liu
2018-05-28  0:43 ` [PATCH bpf-next 11/11] bpf, doc: add missing patchwork url and libbpf to maintainers Daniel Borkmann
2018-05-30  0:16   ` Song Liu

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=20180529192324.7a1db7ee@redhat.com \
    --to=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --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.