Re: commit 662dc80a5e86 breaks rmnet over usb

[Laurent Vivier <lvivier@redhat.com>]

On 2/25/26 08:19, Daniele Palmas wrote:
> Hello,

Hello Daniele,

> 
> Il giorno lun 23 feb 2026 alle ore 15:08 Laurent Vivier
> <lvivier@redhat.com> ha scritto:
>>
>> On 2/23/26 13:04, Koen Vandeputte wrote:
>>> Hi Laurent,
>>
>> Hi Koen,
>>
>>> I'm testing the latest openwrt state and found an issue probably
>>> caused by your usb mtu limit patch :-)
>>>
>>> I'm talking about this one:
>>> 662dc80a5e86 ("usbnet: limit max_mtu based on device's hard_mtu")
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.12.74&id=662dc80a5e86b35bbf339e0b87b7cc3f07c09de1
>>>
>>>
>>> When using wwan0 iface normally, this makes sense, but the problem is
>>> when using QMI modems combined with the rmnet driver and aggregated
>>> frames.
>>>
>>> - The modem is configured to frame sizes of 16383 or 32767 using QMI
>>> - wwan0 (using qmi_wwan) is configured to match this frame size by
>>> setting it's MTU to the same value
>>> - Frames of this size are sent over to qmi_wwan driver (containing
>>> multiple data packets)
>>> - Frames are then forwarded to the rmnet driver
>>> - Frames get de-aggregated here and sent to the network stack for processing.
>>>
>>> The reason here is to reduce USB transfers heavily.
>>>
>>>
>>> As you see, it's perfectly possible here to use very large MTU sizes
>>> as the aggregation feature by rmnet relies on this.
>>> Also the modem can be perfectly configured to send very large aggregated frames.
>>>
>>> After your patch, wwan0 is limited to 1500 bytes it seems, effectively
>>> breaking aggregation.
>>>
>>> On my tests, download speeds are reduced from >300Mbps to ~.8Mbps
>>>
>>> I also made a build reverting this patch and all works well again.
>>>
>>>
>>> Is there any other solution to fix this?
>>> I guess it should be reverted otherwise :-)
>>
>> It's weird to be able to set an MTU that is not supported by the hardware.
>>
>> To restore performance I think the rx_usb_size should be decoupled from MTU max in qmi_wwan.
>>
>> 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.
> 
> 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.

And there is no intermediate driver (qmi_wwan or rmnet) that can define a max_mtu higher 
than that defined by usbnet?

Thanks,
Laurent