Netdev Archive on lore.kernel.org help / color / mirror / Atom feed
From: "Bjørn Mork" <bjorn@mork.no> To: subashab@codeaurora.org Cc: Aleksander Morgado <aleksander@aleksander.es>, Daniele Palmas <dnlplm@gmail.com>, Network Development <netdev@vger.kernel.org>, Sean Tranchetti <stranche@codeaurora.org> Subject: Re: RMNET QMAP data aggregation with size greater than 16384 Date: Fri, 06 Aug 2021 21:58:02 +0200 [thread overview] Message-ID: <87bl6aqrat.fsf@miraculix.mork.no> (raw) In-Reply-To: <13972ac97ffe7a10fd85fe03dc84dc02@codeaurora.org> (subashab@codeaurora.org's message of "Fri, 06 Aug 2021 12:42:49 -0600") subashab@codeaurora.org writes: > Unfortunately, this seems to be a limitation of qmi_wwan (usbnet) > where its tying the RX to the TX size through usbnet_change_mtu. > > Ideally, we should break this dependency and have a sysfs or some other > configuration scheme to set the rx_urb_size. > > Looks like this discussion has happened a while back and the option to > use > a configurable scheme for rx_urb_size was rejected by Bjorn and Greg KH. Ouch, I never meant to shoot down the proposal. I had to go back and read my comments. I see that it might have come out that way... My main point was that I'd prefer this to work without any userspace invervention, if possible. And I'm still not sure we've explored that alternative to the end? > The summary of the thread was to set a large rx_urb_size during probe > itself for qmi_wwan. Yes, I think it would be good to make the driver DTRT automatically. Coding driver specific quirks into ModemManager might work, but it feels wrong to work around a Linux driver bug. We don't have to do that. We can fix the driver. > https://patchwork.kernel.org/project/linux-usb/patch/20200803065105.8997-1-yzc666@netease.com/ > > We could try setting a large value as suggested there and it should > hopefully > solve the issue you are seeing. Why can't we break the rx_urb_size dependency on MTU automatically when pass_through or qmi_wwan internal muxing is enabled? Preferably with some fixed default size which would Just Work for everyone. I'm not rejecting a rx_urb_size knob if it is absolutely necessary. But I hope someone will write a good explanation on how to tune that value then. Knobs are only useful if the user can make an intelligent choice. This should go into the ABI docs. Bjørn
next prev parent reply other threads:[~2021-08-06 19:58 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-31 22:45 RMNET QMAP data aggregation with size greater than 16384 Aleksander Morgado 2021-08-05 19:10 ` subashab 2021-08-05 20:32 ` Aleksander Morgado [not found] ` <CAGRyCJHYkH4_FvTzk7BFwjMN=iOTN_Y2=4ueY=s3rJMQO9j7uw@mail.gmail.com> 2021-08-05 21:01 ` Aleksander Morgado 2021-08-05 21:12 ` Daniele Palmas 2021-08-05 22:57 ` subashab 2021-08-06 14:08 ` Aleksander Morgado 2021-08-06 18:42 ` subashab 2021-08-06 19:58 ` Bjørn Mork [this message] 2021-08-06 20:22 ` Aleksander Morgado 2021-08-06 22:30 ` subashab 2021-08-07 10:55 ` Bjørn Mork 2021-08-09 21:40 ` subashab 2021-08-12 12:02 ` Daniele Palmas 2021-08-13 6:21 ` subashab 2021-08-13 6:25 ` Bjørn Mork 2021-09-03 13:55 ` Daniele Palmas 2021-09-08 6:21 ` subashab
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87bl6aqrat.fsf@miraculix.mork.no \ --to=bjorn@mork.no \ --cc=aleksander@aleksander.es \ --cc=dnlplm@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=stranche@codeaurora.org \ --cc=subashab@codeaurora.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).