From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Lorenzo Bianconi <lorenzo@kernel.org>,
bpf@vger.kernel.org, netdev@vger.kernel.org
Cc: lorenzo.bianconi@redhat.com, davem@davemloft.net,
kuba@kernel.org, ast@kernel.org, daniel@iogearbox.net,
dsahern@kernel.org, komachi.yoshiki@gmail.com, brouer@redhat.com,
memxor@gmail.com, andrii.nakryiko@gmail.com
Subject: Re: [RFC bpf-next 1/2] net: bridge: add unstable br_fdb_find_port_from_ifindex helper
Date: Mon, 24 Jan 2022 18:50:57 +0100 [thread overview]
Message-ID: <878rv558fy.fsf@toke.dk> (raw)
In-Reply-To: <720907692575488526f06edc2cf5c8f783777d4f.1643044381.git.lorenzo@kernel.org>
[ snip to focus on the API ]
> +int br_fdb_find_port_from_ifindex(struct xdp_md *xdp_ctx,
> + struct bpf_fdb_lookup *opt,
> + u32 opt__sz)
> +{
> + struct xdp_buff *ctx = (struct xdp_buff *)xdp_ctx;
> + struct net_bridge_port *port;
> + struct net_device *dev;
> + int ret = -ENODEV;
> +
> + BUILD_BUG_ON(sizeof(struct bpf_fdb_lookup) != NF_BPF_FDB_OPTS_SZ);
> + if (!opt || opt__sz != sizeof(struct bpf_fdb_lookup))
> + return -ENODEV;
Why is the BUILD_BUG_ON needed? Or why is the NF_BPF_FDB_OPTS_SZ
constant even needed?
> + rcu_read_lock();
This is not needed when the function is only being called from XDP...
> +
> + dev = dev_get_by_index_rcu(dev_net(ctx->rxq->dev), opt->ifindex);
> + if (!dev)
> + goto out;
> +
> + if (unlikely(!netif_is_bridge_port(dev)))
> + goto out;
> +
> + port = br_port_get_check_rcu(dev);
> + if (unlikely(!port || !port->br))
> + goto out;
> +
> + dev = __br_fdb_find_port(port->br->dev, opt->addr, opt->vid, true);
> + if (dev)
> + ret = dev->ifindex;
> +out:
> + rcu_read_unlock();
> +
> + return ret;
> +}
> +
> struct net_bridge_fdb_entry *br_fdb_find_rcu(struct net_bridge *br,
> const unsigned char *addr,
> __u16 vid)
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 2661dda1a92b..64d4f1727da2 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -18,6 +18,7 @@
> #include <linux/if_vlan.h>
> #include <linux/rhashtable.h>
> #include <linux/refcount.h>
> +#include <linux/bpf.h>
>
> #define BR_HASH_BITS 8
> #define BR_HASH_SIZE (1 << BR_HASH_BITS)
> @@ -2094,4 +2095,15 @@ void br_do_proxy_suppress_arp(struct sk_buff *skb, struct net_bridge *br,
> void br_do_suppress_nd(struct sk_buff *skb, struct net_bridge *br,
> u16 vid, struct net_bridge_port *p, struct nd_msg *msg);
> struct nd_msg *br_is_nd_neigh_msg(struct sk_buff *skb, struct nd_msg *m);
> +
> +#define NF_BPF_FDB_OPTS_SZ 12
> +struct bpf_fdb_lookup {
> + u8 addr[ETH_ALEN]; /* ETH_ALEN */
> + u16 vid;
> + u32 ifindex;
> +};
It seems like addr and ifindex should always be required, right? So why
not make them regular function args? That way the ptr to eth addr could
be a ptr directly to the packet header (saving a memcpy), and the common
case(?) could just pass a NULL opts struct?
> +int br_fdb_find_port_from_ifindex(struct xdp_md *xdp_ctx,
> + struct bpf_fdb_lookup *opt,
> + u32 opt__sz);
It should probably be documented that the return value is an ifindex as
well; I guess one of the drawbacks of kfunc's relative to regular
helpers is that there is no convention for how to document their usage -
maybe we should fix that before we get too many of them? :)
-Toke
next prev parent reply other threads:[~2022-01-24 17:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-24 17:20 [RFC bpf-next 0/2] introduce bpf fdb lookup helper for xdp Lorenzo Bianconi
2022-01-24 17:20 ` [RFC bpf-next 1/2] net: bridge: add unstable br_fdb_find_port_from_ifindex helper Lorenzo Bianconi
2022-01-24 17:50 ` Toke Høiland-Jørgensen [this message]
2022-01-26 11:42 ` Lorenzo Bianconi
2022-01-26 12:03 ` Kumar Kartikeya Dwivedi
2022-01-26 20:11 ` Andrii Nakryiko
2022-01-26 12:03 ` Toke Høiland-Jørgensen
2022-01-26 14:04 ` Lorenzo Bianconi
2022-01-24 18:32 ` Nikolay Aleksandrov
2022-01-24 18:32 ` [Bridge] " Nikolay Aleksandrov
2022-01-25 5:09 ` Alexei Starovoitov
2022-01-25 5:09 ` [Bridge] " Alexei Starovoitov
2022-01-26 11:09 ` Lorenzo Bianconi
2022-01-26 11:09 ` [Bridge] " Lorenzo Bianconi
2022-01-26 12:02 ` Toke Høiland-Jørgensen
2022-01-26 12:02 ` [Bridge] " Toke Høiland-Jørgensen
2022-01-26 11:27 ` Lorenzo Bianconi
2022-01-26 11:27 ` [Bridge] " Lorenzo Bianconi
2022-01-26 12:08 ` Kumar Kartikeya Dwivedi
2022-01-26 12:08 ` [Bridge] " Kumar Kartikeya Dwivedi
2022-01-26 12:39 ` Nikolay Aleksandrov
2022-01-26 12:39 ` [Bridge] " Nikolay Aleksandrov
2022-01-26 12:50 ` Toke Høiland-Jørgensen
2022-01-26 12:50 ` [Bridge] " Toke Høiland-Jørgensen
2022-01-26 12:57 ` Nikolay Aleksandrov
2022-01-26 12:57 ` [Bridge] " Nikolay Aleksandrov
2022-01-26 15:00 ` Lorenzo Bianconi
2022-01-26 15:00 ` [Bridge] " Lorenzo Bianconi
2022-01-24 17:20 ` [RFC bpf-next 2/2] samples: bpf: add xdp fdb lookup program Lorenzo Bianconi
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=878rv558fy.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=komachi.yoshiki@gmail.com \
--cc=kuba@kernel.org \
--cc=lorenzo.bianconi@redhat.com \
--cc=lorenzo@kernel.org \
--cc=memxor@gmail.com \
--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.