On Fri, Mar 08, 2019 at 08:51:03PM +0000, Saeed Mahameed wrote:
It's certainly an interesting idea. I think we need to agree on use cases
and goals first before bikesheding on the solution.
this bit show cases advantage of BTF nicely.
2) Setup XDP tx redirect resources on egress netdev (netdev with no XDPthis one starting to become a bit odd, since input arguments are split
between key an value. ifindex is part of the key whereas command,
rings.num and rings.size are part of the value.
3) Turn On/Off XDP meta data offloads and retrieve meta data BTF formathere it gets even weirder, since lookup arguments are also
split between key and value.
ifindex is inside the key while addition info is passed
inside xdp_attr which is part of value.
I wish we could do maps where every key would have different layout.
Then such api would be suitable.
The existing maps require all keys and values to be inform.
I guess one can argue that such 'control map' can have one element
and one value, but then what is the purpose of 'map_create'
and 'map_delete==close(fd)' operations?
I think we need something else here. Using BTF to describe
output stats is nice, but using BTF to describe input query is problematic,
since user cannot know before hand what kernel can and cannot accept.
imo input should be stable uapi with fixed constants whereas
stats-like output can be BTF based and vary from driver to driver
and from one nic version to another.