On Fri, Jul 24, 2026 at 12:58:17PM -0700, Jakub Kicinski wrote: > On Fri, 24 Jul 2026 09:39:54 -0700 Bobby Eshleman wrote: > > > BTW did you add both min and max checks? Cause the only risk with using > > > a dummy value would be that the policy will be rendered inline, and > > > inline policy is u16 so 64k wouldn't fit. But your sample above has a > > > max of u32_max which forces the out-of-line policy, which is what we > > > want. > > > > Yep, u32_max: > > > > + name: rx-page-size > > ... > > + checks: > > + min: page-size > > + max: u32-max > > > > Sorry, probably should have just sent the whole patch instead of > > replying hunk-by-hunk. > > Ack, LG, just double checking. > > > BTW, how expressive do we want these policies? For example, would > > absorbing the power_of_2 check into a policy be valid in the future? or > > is that too bespoke? > > Power-of-2 could be useful (it's implicitly one bit set, which is also > potentially useful for validating one-hot flags). The trickiness is > combining power-of-2 and the min check :S We have one validation per > field. I was wondering if we would be better off defining the field > as a shift instead, then we only have to check min. But I thought > that it'd be a little unusual for uAPI and possibly maybe one day > we will want the non-power of 2? So I figured checking min using > the existing facilities and open coding power of two check is good > enough for now.
SGTM.
