[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP01T75Q8JhX-EQVp_3C9YAxybptUBmuwALsxAaDZObYuQ8KCw@mail.gmail.com>
Date: Fri, 19 Aug 2022 07:24:06 +0200
From: Kumar Kartikeya Dwivedi <memxor@...il.com>
To: sdf@...gle.com
Cc: Toke Høiland-Jørgensen <toke@...hat.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <martin.lau@...ux.dev>,
Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>, Hao Luo <haoluo@...gle.com>,
Jiri Olsa <jolsa@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Jesper Dangaard Brouer <hawk@...nel.org>,
Björn Töpel <bjorn@...nel.org>,
Magnus Karlsson <magnus.karlsson@...el.com>,
Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
Jonathan Lemon <jonathan.lemon@...il.com>, bpf@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH bpf-next 0/3] A couple of small refactorings of BPF
program call sites
On Fri, 19 Aug 2022 at 00:29, <sdf@...gle.com> wrote:
>
> On 08/18, Toke H�iland-J�rgensen wrote:
> > Stanislav suggested[0] that these small refactorings could be split out
> > from the
> > XDP queueing RFC series and merged separately. The first change is a small
> > repacking of struct softnet_data, the others change the BPF call sites to
> > support full 64-bit values as arguments to bpf_redirect_map() and as the
> > return
> > value of a BPF program, relying on the fact that BPF registers are always
> > 64-bit
> > wide to maintain backwards compatibility.
>
> > Please see the individual patches for details.
>
> > [0]
> > https://lore.kernel.org/r/CAKH8qBtdnku7StcQ-SamadvAF==DRuLLZO94yOR1WJ9Bg=uX1w@mail.gmail.com
>
> Looks like a nice cleanup to me:
> Reviewed-by: Stanislav Fomichev <sdf@...gle.com>
>
> Can you share more on this comment?
>
> /* For some architectures, we need to do modulus in 32-bit width */
>
> Some - which ones? And why do they need it to be 32-bit?
It was a fix for i386, I saw a kernel test robot error when it was
sitting in Toke's tree.
See https://lore.kernel.org/all/202203140800.8pr81INh-lkp@intel.com.
Once bpf_prog_run_clear_cb starts returning a 64-bit value, we now
need to save it in 32-bit before doing the modulus.
>
> > Kumar Kartikeya Dwivedi (1):
> > bpf: Use 64-bit return value for bpf_prog_run
>
> > Toke H�iland-J�rgensen (2):
> > dev: Move received_rps counter next to RPS members in softnet data
> > bpf: Expand map key argument of bpf_redirect_map to u64
>
> > include/linux/bpf-cgroup.h | 12 +++++-----
> > include/linux/bpf.h | 16 ++++++-------
> > include/linux/filter.h | 46 +++++++++++++++++++-------------------
> > include/linux/netdevice.h | 2 +-
> > include/uapi/linux/bpf.h | 2 +-
> > kernel/bpf/cgroup.c | 12 +++++-----
> > kernel/bpf/core.c | 14 ++++++------
> > kernel/bpf/cpumap.c | 4 ++--
> > kernel/bpf/devmap.c | 4 ++--
> > kernel/bpf/offload.c | 4 ++--
> > kernel/bpf/verifier.c | 2 +-
> > net/bpf/test_run.c | 21 +++++++++--------
> > net/core/filter.c | 4 ++--
> > net/packet/af_packet.c | 7 ++++--
> > net/xdp/xskmap.c | 4 ++--
> > 15 files changed, 80 insertions(+), 74 deletions(-)
>
> > --
> > 2.37.2
>
Powered by blists - more mailing lists