On Tue, 11 Jul 2023 18:59:51 +0200 Alexander Lobakin wrote: > From: Jakub Kicinski <kuba@xxxxxxxxxx> > Date: Tue, 11 Jul 2023 09:37:05 -0700 > > > On Tue, 11 Jul 2023 12:59:00 +0200 Alexander Lobakin wrote: > >> I'm fine with that, although ain't really able to work on this myself > >> now :s (BTW I almost finished Netlink bigints, just some more libie/IAVF > >> crap). > > > > FWIW I was thinking about the bigints recently, and from ynl > > perspective I think we may want two flavors :( One which is at > > most the length of platform's long long, and another which is > > `long long` or `long`? `long long` is always 64-bit unless I'm missing > something. On my 32-bit MIPS they were :D > If `long long`, what's the point then if we have %NLA_U64 and would > still have to add dumb padding attrs? :D I thought the idea was to carry > 64+ bits encapsulated in 32-bit primitives. Sorry I confused things. Keep in mind we're only talking about what the generated YNL code ends up looking like, not the "wire" format. So we still "transport" things as multiple 32b chunks at netlink level. No padding. The question is how to render the C / C++ code on the YNL side (or any practical library). Are we storing all those values as bigints and require users to coerce them to a more natural type on each access? That'd defeat the goal of the new int type becoming the default / "don't overthink the sizing" type. If we have a subtype with a max size of 64b, it can be 32b or 64b on the wire, as needed, but user space can feel assured that u64 will always be able to store the result. The long long is my misguided attempt to be platform dependent. I think a better way of putting it would actually be 2 * sizeof(long). That way we can use u128 as max, which seems to only be defined on 64b platforms. But that's just a random thought, I'm not sure how useful it would be. Perhaps we need two types, one "basic" which tops out at 64b and one "really bigint" which can be used as bitmaps as well?
