Re: commit 662dc80a5e86 breaks rmnet over usb

[Daniele Palmas]

Hello Jakub,

Il giorno gio 26 feb 2026 alle ore 02:01 Jakub Kicinski
<kuba@xxxxxxxxxx> ha scritto:
>
> On Wed, 25 Feb 2026 08:19:46 +0100 Daniele Palmas wrote:
> > > Could you try something like:
> > >
> > > diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> > > index 3a4985b582cb..6b4796fac692 100644
> > > --- a/drivers/net/usb/qmi_wwan.c
> > > +++ b/drivers/net/usb/qmi_wwan.c
> > > @@ -788,6 +788,8 @@ static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf)
> > >                  usbnet_get_ethernet_addr(dev, cdc_ether->iMACAddress);
> > >          }
> > >
> > > +       dev->rx_urb_size = 32768;
> > > +
> >
> > So far userspace tools (e.g. also the most important one which is
> > ModemManager) rely on changing the rx_urb_size by changing the MTU: I
> > know this is ugly, but it is a behavior that has been there since a
> > lot of time, not sure how many tools based on this assumption could
> > break.
>
> What's the policy in ModemManager to change the rx_urb_size?
> Increase it to make sure it can hold some specific cmd / packet?
>
> I wonder if having rx_urb_size max of (mtu, 32k) would break anything.
>

Typically the host sends a QMI request to the modem for setting the
size of the maximum QMAP aggregated packets block. Then the modem
replies with the maximum size it supports and that one is then set by
the host through changing the MTU of the netdevice. Low-cat modems
usually support 4-8 KB, while 5G 16-32KB.

On ModemManager side this is currently fixed at 16KB, but one can use
other tools e.g. qmicli to set custom values as far as they are
supported by the modem.

> Since we're talking about rx buffer config the right API to configure
> it is likely ethtool -G rx-buf-len :(
>

Thanks for the hint, I'll try to have a look at that to improve qmi_wwan.

> > There's also the chance that there are modems which require a higher
> > rx_urb_size, so having this fixed could not work well.
> >
> > Unfortunately usbnet serves many drivers, I agree with Koen that a
> > revert is the safest option.
>
> Then again the usbnet driver is brittle enough as is, if it's just qmi
> that needs this workaround we would be making common code less robust
> for a benefit of a single "hack" (for lack of a better term)

Makes sense, also Laurent proposed a solution to keep his fix in
usbnet and make qmi_wwan the exception.

Regards,
Daniele