All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Shay Agroskin <shayagr@amazon.com>
Cc: Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Alexei Starovoitov <ast@fb.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	David Ahern <dsahern@gmail.com>, Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v4 bpf-next 3/9] bpf, xdp: extract common XDP program attachment logic
Date: Mon, 27 Jul 2020 11:51:35 -0700	[thread overview]
Message-ID: <CAEf4Bzb1_mQVxjmLEK0OFBdfnFi8To4fH-=kJTs8nz6xq7zUMw@mail.gmail.com> (raw)
In-Reply-To: <pj41zla6zl88le.fsf@ua97a68a4e7db56.ant.amazon.com>

On Mon, Jul 27, 2020 at 5:08 AM Shay Agroskin <shayagr@amazon.com> wrote:
>
>
> Andrii Nakryiko <andriin@fb.com> writes:
>
> > Further refactor XDP attachment code. dev_change_xdp_fd() is
> > split into two
> > parts: getting bpf_progs from FDs and attachment logic, working
> > with
> > bpf_progs. This makes attachment  logic a bit more
> > straightforward and
> > prepares code for bpf_xdp_link inclusion, which will share the
> > common logic.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> >  net/core/dev.c | 165
> >  +++++++++++++++++++++++++++----------------------
> >  1 file changed, 91 insertions(+), 74 deletions(-)
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 7e753e248cef..abf573b2dcf4 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -8815,111 +8815,128 @@ static void dev_xdp_uninstall(struct
> > net_device *dev)
> >       }
> >  }
> >
> > -/**
> > - *   dev_change_xdp_fd - set or clear a bpf program for a
> > device rx path
> > - *   @dev: device
> > - *   @extack: netlink extended ack
> > - *   @fd: new program fd or negative value to clear
> > - *   @expected_fd: old program fd that userspace expects to
> > replace or clear
> > - *   @flags: xdp-related flags
> > - *
> > - *   Set or clear a bpf program for a device
> > - */
> > -int dev_change_xdp_fd(struct net_device *dev, struct
> > netlink_ext_ack *extack,
> > -                   int fd, int expected_fd, u32 flags)
> > +static int dev_xdp_attach(struct net_device *dev, struct
> > netlink_ext_ack *extack,
> > +                       struct bpf_prog *new_prog, struct
> > bpf_prog *old_prog,
> > +                       u32 flags)
> >  {
> > -     const struct net_device_ops *ops = dev->netdev_ops;
> > -     enum bpf_xdp_mode mode = dev_xdp_mode(flags);
> > -     bool offload = mode == XDP_MODE_HW;
> > -     u32 prog_id, expected_id = 0;
> > -     struct bpf_prog *prog;
> > +     struct bpf_prog *cur_prog;
> > +     enum bpf_xdp_mode mode;
> >       bpf_op_t bpf_op;
> >       int err;
> >
> >       ASSERT_RTNL();
> >
> > -     bpf_op = dev_xdp_bpf_op(dev, mode);
> > -     if (!bpf_op) {
> > -             NL_SET_ERR_MSG(extack, "underlying driver does not
> > support XDP in native mode");
> > -             return -EOPNOTSUPP;
> > +     /* just one XDP mode bit should be set, zero defaults to
> > SKB mode */
> > +     if (hweight32(flags & XDP_FLAGS_MODES) > 1) {
>
> Not sure if it's more efficient but running
>     if ((flags & XDP) & ((flags & XDP) - 1) != 0)
>
> returns whether a number is a multiple of 2.
> Should be equivalent to what you checked with hweight32. It is
> less readable though. Just thought I'd throw that in.

so I just preserved what is there in netlink-handling code. It also is
not a performance-critical part. What you propose might work, but
using hweight32 is more explicit about allowing zero or one bits set.


> Taken from
> https://graphics.stanford.edu/~seander/bithacks.html#DetermineIfPowerOf2
>
> > +             NL_SET_ERR_MSG(extack, "Only one XDP mode flag can
> > be set");
> > +             return -EINVAL;
> > +     }
> > +     /* old_prog != NULL implies XDP_FLAGS_REPLACE is set */
> > +     if (old_prog && !(flags & XDP_FLAGS_REPLACE)) {
> > +             NL_SET_ERR_MSG(extack, "XDP_FLAGS_REPLACE is not
> > specified");
> > +             return -EINVAL;
> >       }
> >

[...]

  reply	other threads:[~2020-07-27 18:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22  6:45 [PATCH v4 bpf-next 0/9] BPF XDP link Andrii Nakryiko
2020-07-22  6:45 ` [PATCH v4 bpf-next 1/9] bpf: make bpf_link API available indepently of CONFIG_BPF_SYSCALL Andrii Nakryiko
2020-07-22  6:45 ` [PATCH v4 bpf-next 2/9] bpf, xdp: maintain info on attached XDP BPF programs in net_device Andrii Nakryiko
2020-07-22 15:26   ` Maciej Fijalkowski
2020-07-22 19:35     ` Andrii Nakryiko
2020-07-22 19:56       ` Maciej Fijalkowski
2020-07-22  6:45 ` [PATCH v4 bpf-next 3/9] bpf, xdp: extract common XDP program attachment logic Andrii Nakryiko
2020-07-22 19:13   ` Maciej Fijalkowski
2020-07-22 19:29     ` Andrii Nakryiko
2020-07-27 12:07   ` Shay Agroskin
2020-07-27 18:51     ` Andrii Nakryiko [this message]
2020-08-11 18:14   ` sdf
2020-08-12  2:19     ` Andrii Nakryiko
2020-07-22  6:45 ` [PATCH v4 bpf-next 4/9] bpf, xdp: add bpf_link-based XDP attachment API Andrii Nakryiko
2020-07-22  6:45 ` [PATCH v4 bpf-next 5/9] bpf, xdp: implement LINK_UPDATE for BPF XDP link Andrii Nakryiko
2020-07-22  6:45 ` [PATCH v4 bpf-next 6/9] bpf: implement BPF XDP link-specific introspection APIs Andrii Nakryiko
2020-07-22  6:46 ` [PATCH v4 bpf-next 7/9] libbpf: add support for BPF XDP link Andrii Nakryiko
2020-07-22  6:46 ` [PATCH v4 bpf-next 8/9] selftests/bpf: add BPF XDP link selftests Andrii Nakryiko
2020-07-22  6:46 ` [PATCH v4 bpf-next 9/9] bpf, xdp: remove XDP_QUERY_PROG and XDP_QUERY_PROG_HW XDP commands Andrii Nakryiko
2020-07-26  3:46 ` [PATCH v4 bpf-next 0/9] BPF XDP link Alexei Starovoitov

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='CAEf4Bzb1_mQVxjmLEK0OFBdfnFi8To4fH-=kJTs8nz6xq7zUMw@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dsahern@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=shayagr@amazon.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.