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", > BTF_TYPE_INT); > 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.
