Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Aleksander Morgado <aleksander@aleksander.es>
To: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Cc: "Bjørn Mork" <bjorn@mork.no>, "Daniele Palmas" <dnlplm@gmail.com>,
"Network Development" <netdev@vger.kernel.org>,
stranche@codeaurora.org
Subject: Re: RMNET QMAP data aggregation with size greater than 16384
Date: Thu, 5 Aug 2021 22:32:45 +0200 [thread overview]
Message-ID: <CAAP7ucK7EeBPJHt9XFp7bd5cGXtH5w2VGgh3yD7OA9SYd5JkJw@mail.gmail.com> (raw)
In-Reply-To: <c0e14605e9bc650aca26b8c3920e9aba@codeaurora.org>
Hey Subash,
> > I'm playing with the whole QMAP data aggregation setup with a USB
> > connected Fibocom FM150-AE module (SDX55).
> > See https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/issues/71
> > for some details on how I tested all this.
> >
> > This module reports a "Downlink Data Aggregation Max Size" of 32768
> > via the "QMI WDA Get Data Format" request/response, and therefore I
> > configured the MTU of the master wwan0 interface with that same value
> > (while in 802.3 mode, before switching to raw-ip and enabling
> > qmap-pass-through in qmi_wwan).
> >
> > When attempting to create a new link using netlink, the operation
> > fails with -EINVAL, and following the code path in the kernel driver,
> > it looks like there is a check in rmnet_vnd_change_mtu() where the
> > master interface MTU is checked against the RMNET_MAX_PACKET_SIZE
> > value, defined as 16384.
> >
> > If I setup the master interface with MTU 16384 before creating the
> > links with netlink, there's no error reported anywhere. The FM150
> > module crashes as soon as I connect it with data aggregation enabled,
> > but that's a different story...
> >
> > Is this limitation imposed by the RMNET_MAX_PACKET_SIZE value still a
> > valid one in this case? Should changing the max packet size to 32768
> > be a reasonable approach? Am I doing something wrong? :)
> >
> > This previous discussion for the qmi_wwan add_mux/del_mux case is
> > relevant:
> > https://patchwork.ozlabs.org/project/netdev/patch/20200909091302.20992-1-dnlplm@gmail.com/..
> > The suggested patch was not included yet in the qmi_wwan driver and
> > therefore the user still needs to manually configure the MTU of the
> > master interface before setting up all the links, but at least there
> > seems to be no maximum hardcoded limit.
> >
> > Cheers!
>
> Hi Aleksander
>
> The downlink data aggregation size shouldn't affect the MTU.
> MTU applies for uplink only and there is no correlation with the
> downlink path.
> Ideally, you should be able to use standard 1500 bytes (+ additional
> size for MAP header)
> for the master device. Is there some specific network which is using
> greater than 1500 for the IP packet itself in uplink.
>
I may be mistaken then in how this should be setup when using rmnet.
For the qmi_wwan case using add_mux/del_mux (Daniele correct me if
wrong!), we do need to configure the MTU of the master interface to be
equal to the aggregation data size reported via QMI WDA before
creating any mux link; see
http://paldan.altervista.org/linux-qmap-qmi_wwan-multiple-pdn-setup/
I ended up doing the same here for the rmnet case; but if it's not
needed I can definitely change that. I do recall that I originally had
left the master MTU untouched in the rmnet case and users had issues,
and increasing it to the aggregation size solved that; I assume that's
because the MTU should have been increased to accommodate the extra
MAP header as you said. How much more size does it need on top of the
1500 bytes?
--
Aleksander
https://aleksander.es
next prev parent reply other threads:[~2021-08-05 20:33 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 [this message]
[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
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=CAAP7ucK7EeBPJHt9XFp7bd5cGXtH5w2VGgh3yD7OA9SYd5JkJw@mail.gmail.com \
--to=aleksander@aleksander.es \
--cc=bjorn@mork.no \
--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: link
Be 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).