Re: [PATCH net-next v5 1/3] net: devmem: allow rx-buf-size > PAGE_SIZE per dmabuf binding

[Bobby Eshleman <bobbyeshleman@gmail.com>]

On Fri, Jul 24, 2026 at 07:24:19AM -0700, Jakub Kicinski wrote:
> On Thu, 23 Jul 2026 16:58:14 -0700 Bobby Eshleman wrote:
> > > > +	if (info->attrs[NETDEV_A_DMABUF_RX_BUF_SIZE]) {
> > > > +		u32 rx_buf_size = nla_get_u32(info->attrs[NETDEV_A_DMABUF_RX_BUF_SIZE]);
> > > > +
> > > > +		if (!rx_buf_size || !is_power_of_2(rx_buf_size) ||
> > > > +		    rx_buf_size < PAGE_SIZE) {  
> > > 
> > > we should add a check: min: page-size in the Netlink policy?  
> > 
> > I played around with this adding:
> > 
> > Documentation/netlink/specs/netdev.yaml:
> >  definitions:
> >  +  -
> >  +    type: const
> >  +    name: page-size
> >  +    value: 4096  # dummy value, to pass ynl_gen_c.py checks
> >  +    header: asm/page.h
> >  +    scope: kernel
> > 
> > Generating:
> > 
> > +static const struct netlink_range_validation
> > netdev_a_dmabuf_rx_page_size_range = {
> > +       .min    = PAGE_SIZE,
> > +       .max    = U32_MAX,
> > +};
> > +
> > 
> > ... but the dummy 4096 is kind of annoying. ynl_gen_c.py can't know the
> > value of PAGE_SIZE but needs some value for its arithmetic checks (e.g.,
> > confirm min < max is true).
> > 
> > Should we stick with using a dummy value, or should we add a patch
> > teaching ynl_gen_c.py to allow value-less consts (skip the arithmetic
> > checks)? 
> 
> Let's stick to a dummy one for now, but maybe something obviously dummy
> like 0 ?

0 sounds good to me.

> 
> 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.

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?

Best,
Bobby