modem: modem_cellular: Configurable MTU for CMUX

[SeppoTakalo]

Allow configuring MTU for CMUX.
Some AT manual and specification define this as a
frame size. Linux ldattach default to 127 bytes,
3GPP TS 27.010 defaults to 31.

We should limit our CMUX frames to a size that
remote end is capable of handling.
Linux silently drops oversized frames.

Also, deprecate MODEM_CELLULAR_CMUX_MAX_FRAME_SIZE as this was only limiting a buffer sizes, and resulted CMUX frames to be capped to same value.
Use MODEM_CMUX_WORK_BUFFER_SIZE and MODEM_CMUX_MTU instead.

For reference:
Linux kernel n_gsm.c driver on receiving side: https://elixir.bootlin.com/linux/v6.13.6/source/drivers/tty/n_gsm.c#L2885
You can see that all frames larger than MTU/MRU are silently dropped.

ldattach(8) utility from Util-linux package: https://github.com/util-linux/util-linux/blob/master/sys-utils/ldattach.c#L260-L276 you can see that it sets default to 127 and there is no command line parameters to configure this.

[bjarki-andreasen]

I like it :)

[SeppoTakalo]

Rebased on top of main and fixed the conflict on migration-guide-4.2.rst

[SeppoTakalo]

Please merge this soon, as I would otherwise have to constantly rebase it on top of main, because changelog keeps changing and I get conflicts.

[tomi-font]

I see. I renamed the Kconfig as I want to keep all DLCI buffers to same as CMUX size. It seem to work OK and we then save lots of RAM.

Uhm, weird numbers considering your changes (regarding ROM), are you sure your branch is based off the same main as what you are using for comparison?

Also, of course you'll get big RAM savings for nrf9160dk/nrf52840 by changing the buffer sizes from 1500 to 38, but I think this is gonna be very sub-ideal for the bandwidth as every PPP frame will be very small due to the CMUX MTU.
For the SLM-based board targets I'd actually support keeping a bigger CMUX MTU in the sample.

[SeppoTakalo]

Uhm, weird numbers considering your changes (regarding ROM), are you sure your branch is based off the same main as what you are using for comparison?

Not weird numbers. I took a look of why this happens.
struct modem_cellular_data contains all buffers so when all modem instances are defined using static struct modem_cellular_data MODEM_CELLULAR_INST_NAME(data, inst) = {...} then all fields of that struct are stored in flash, and then copied into .datasection.

So even though we only initialize some of the fields, the whole structure is stored. So all buffers are going to be zero initialized.

[SeppoTakalo]

sub-ideal for the bandwidth as every PPP frame will be very small due to the CMUX MTU.

I'm unsure if I follow this correctly. The CMUX MTU does not affect PPP MTU.
One PPP frame might need multiple CMUX frames to be send.

For performance wise, all buffer sizes should be optimized only once you define your final baud rate. So it is pointless to try to tweak them here.

[SeppoTakalo]

Sorry for changing this PR:
I separated the migration guide to its own commit so I'm able to pull these changes in nRF Connect SDK.

Otherwise I would end up conflicting the migration guide again when cherry-picking.

[tomi-font]

Not weird numbers. I took a look of why this happens.
struct modem_cellular_data contains all buffers so when all modem instances are defined using static struct modem_cellular_data MODEM_CELLULAR_INST_NAME(data, inst) = {...} then all fields of that struct are stored in flash, and then copied into .datasection.

So even though we only initialize some of the fields, the whole structure is stored. So all buffers are going to be zero initialized.

Oh wow. That's bad. Wondering what could be done to avoid that. 🤔

I'm unsure if I follow this correctly. The CMUX MTU does not affect PPP MTU.
One PPP frame might need multiple CMUX frames to be send.

Yeah sorry I was too simplistic in what I said. The PPP frames being sent across many small CMUX frames will reduce the MCU <=> modem bandwidth (and increase at least a little bit the processing overhead). But I don't disagree that this needs to be tuned according to every use case and configuration.

[tomi-font]

Sorry for changing this PR:
I separated the migration guide to its own commit so I'm able to pull these changes in nRF Connect SDK.

Otherwise I would end up conflicting the migration guide again when cherry-picking.

The diff didn't change so the reviews weren't dismissed. 🙂