Martin KaFai Lau <martin.lau@xxxxxxxxx> writes: > On 11/10/22 3:29 PM, Toke Høiland-Jørgensen wrote: >>>> For the metadata consumed by the stack right now it's a bit >>>> hypothetical, yeah. However, there's a bunch of metadata commonly >>>> supported by hardware that the stack currently doesn't consume and that >>>> hopefully this feature will end up making more accessible. My hope is >>>> that the stack can also learn how to use this in the future, in which >>>> case we may run out of space. So I think of that bit mostly as >>>> future-proofing... >>> >>> ic. in this case, Can the btf_id be added to 'struct xdp_to_skb_metadata' later >>> if it is indeed needed? The 'struct xdp_to_skb_metadata' is not in UAPI and >>> doing it with CO-RE is to give us flexibility to make this kind of changes in >>> the future. >> >> My worry is mostly that it'll be more painful to add it later than just >> including it from the start, mostly because of AF_XDP users. But if we >> do the randomisation thing (thus forcing AF_XDP users to deal with the >> dynamic layout as well), it should be possible to add it later, and I >> can live with that option as well... > > imo, considering we are trying to optimize unnecessary field > initialization as below, it is sort of wasteful to always initialize > the btf_id with the same value. It is better to add it in the future > when there is a need. Okay, let's omit the BTF ID for now, and see what that looks like. I'll try to keep in mind to see if I can find any reasons why we'd need to add it back and make sure to complain before this lands if I find any :) -Toke
