Re: [RFC][Proposal] BPF Control MAP

Alexei Starovoitov

On Wed, Mar 20, 2019 at 04:47:11AM +0000, Saeed Mahameed wrote:

consider the following command line, with bpftool that compiled way
before xsk-ring-szie attribute was introduced.
perfect. let's agree on the use case first...

$ bpftool xdp set eth0 xsk-ring-size 128
would be great to have. no doubt.

what this can eventually do:

fd = create_map(BPF_CONTROL, map_attr.ctrl_type = XDP_ATTR)

//Query BTF of the control (XDP) map
query_map_attributes(fd, &map_attr);
and bpf_map_info returns btf_key_type_id and btf_value_type_id
Are you saying btf_key_type_id will return single u32 with name 'ifindex' ?
Where do you specify netns_id+dev_id ?

// Find if control map values btf layout include the new member
offset = btf_get_offset_of_memeber_name(map_attr.btf, "xsk-ring-size",
if (offset < 0)
return offset; // the new member is not supported in kernel

*(value + offset) = (int)new_val;
map_update(fd, <eth0 ifindex>, value);
what about other fields in this value ?
If zero do not update ?
Shouldn't it be read/modify/write ?
So lookup everything first, modify only that '*(value + offset)'
and do map_update ?
and the driver received full blob of bytes for all fields.
What driver suppose to do ? Rewrite all fields ?
Or try to be smart and do read+if_not_the_same_write ?

Different ifindexes will be different drivers,
so single map providing single btf_value_type_id for all of them
isn't going to work.

I hope you see that such api is falling apart even for simplest use case.

Join to automatically receive all group messages.