Re: [PATCH bpf-next 4/6] bpf: cpumap: add the possibility to attach an eBPF program to cpumap

[Jesper Dangaard Brouer <brouer@xxxxxxxxxx>]

On Sun, 31 May 2020 23:46:49 +0200
Lorenzo Bianconi <lorenzo@xxxxxxxxxx> wrote:

> diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c
> index 57402276d8af..24ab0a6b9772 100644
> --- a/kernel/bpf/cpumap.c
> +++ b/kernel/bpf/cpumap.c
> @@ -51,6 +51,10 @@ struct xdp_bulk_queue {
>  /* CPUMAP value */
>  struct bpf_cpumap_val {
>  	u32 qsize;	/* queue size */
> +	union {
> +		int fd;	/* program file descriptor */
> +		u32 id;	/* program id */
> +	} prog;
>  };
  
Please name the union 'bpf_prog' and not 'prog'.
We should match what David Ahern did for devmap.

Even-though we are NOT exposing this in the UAPI header-file, this still
becomes a UAPI interface (actually kABI).  The struct member names are
still important, even-though this is a binary layout, because the BTF
info is basically documenting this API.

Notice when kernel is compiled with BTF info, you (or end-user) can use
pahole to "reverse" the struct layout (comments don't survive, so we
need descriptive member names):

$ pahole bpf_devmap_val
struct bpf_devmap_val {
	__u32                      ifindex;              /*     0     4 */
	union {
		int                fd;                   /*     4     4 */
		__u32              id;                   /*     4     4 */
	} bpf_prog;                                      /*     4     4 */
	struct {
		unsigned char      data[24];             /*     8    24 */
	} storage;                                       /*     8    24 */

	/* size: 32, cachelines: 1, members: 3 */
	/* last cacheline: 32 bytes */
};

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


$ bpftool btf dump file /sys/kernel/btf/vmlinux format c | grep -A10 'struct bpf_devmap_val {'
struct bpf_devmap_val {
	__u32 ifindex;
	union {
		int fd;
		__u32 id;
	} bpf_prog;
	struct {
		unsigned char data[24];
	} storage;
};