Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Loic Poulain <loic.poulain@linaro.org>
To: Richard Laing <Richard.Laing@alliedtelesis.co.nz>
Cc: David Miller <davem@davemloft.net>,
Network Development <netdev@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] bus: mhi: pci-generic: configurable network interface MRU
Date: Tue, 27 Jul 2021 11:21:52 +0200 [thread overview]
Message-ID: <CAMZdPi8MZp5Vx_ZnjjQWptms9vj6bEMoV83pcv4wmgxbZz0wjQ@mail.gmail.com> (raw)
In-Reply-To: <5165a859-1b00-e50e-985e-25044cf0e9ec@alliedtelesis.co.nz>
On Mon, 19 Jul 2021 at 23:44, Richard Laing
<Richard.Laing@alliedtelesis.co.nz> wrote:
>
> Hi Loic,
>
> On 7/19/21 10:11 PM, Loic Poulain wrote:
> > For my interest do you have some numbers here highlighting improvement?
> These are some of the numbers we found from initial testing using an
> external packet generator:
>
> packet size packets sent throughput (%pps)
> 64 1000000 6.21%
> 128 1000000 7.42%
> 256 1000000 10.79%
> 512 1000000 16.40%
> 1024 1000000 34.34%
> 1262 1000000 43.82%
> 1263 1000000 22.45% <--
> 1280 1000000 23.15%
> 1500 1000000 46.32%
> 1518 1000000 46.84%
>
> You can see the sudden drop of almost 50% between 1262 and 1263 byte
> packets. This is what caused us to investigate further. Following the
> change to 32KB buffers the drop in throughput is no longer seen.
>
> packet size packets sent throughput (%pps)
> 64 1000000 4.41%
> 128 1000000 7.70%
> 256 1000000 14.26%
> 512 1000000 27.06%
> 1024 1000000 49.39%
> 1280 1000000 58.82%
> 1428 1000000 62.63%
>
> In all cases we were testing with the modem itself in internal loopback
> mode.
>
> We have noted that our modem defaults to 32KB buffers (and a maximum of
> 32 packets per buffer) and also that these values can be changed. We are
> considering adding the ability to tune the buffer size, perhaps adding a
> sysfs entry or netlink message to change the buffer size instead of the
> hard coded value. Any comments would be appreciated.
Thanks for the info, that's interesting.
Note that the default MRU you define is not MHI controller specific
but MHI channel specific (IP/MBIM channel), so it should not be a
property of the MHI controller. AFAIK, The MHI specification already
defines MRU for the transfered buffers which is 65535. I would
recommend to move this prop to the channel config.
Regards,
Loic
>
> Regards,
> Richard
>
>
>
next prev parent reply other threads:[~2021-07-27 9:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-14 21:18 richard.laing
2021-07-15 17:20 ` patchwork-bot+netdevbpf
2021-07-19 10:11 ` Loic Poulain
2021-07-19 21:44 ` Richard Laing
2021-07-27 9:21 ` Loic Poulain [this message]
2021-07-27 20:49 ` Richard Laing
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=CAMZdPi8MZp5Vx_ZnjjQWptms9vj6bEMoV83pcv4wmgxbZz0wjQ@mail.gmail.com \
--to=loic.poulain@linaro.org \
--cc=Richard.Laing@alliedtelesis.co.nz \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--subject='Re: [PATCH] bus: mhi: pci-generic: configurable network interface MRU' \
/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
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).