linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Laing <Richard.Laing@alliedtelesis.co.nz>
To: Loic Poulain <loic.poulain@linaro.org>
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: Mon, 19 Jul 2021 21:44:33 +0000	[thread overview]
Message-ID: <5165a859-1b00-e50e-985e-25044cf0e9ec@alliedtelesis.co.nz> (raw)
In-Reply-To: <CAMZdPi-1E5pieVwt_XFF-+PML-cX05nM=PdD0pApD_ym5k_uMQ@mail.gmail.com>

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.

Regards,
Richard




  reply	other threads:[~2021-07-20  3:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14 21:18 [PATCH] bus: mhi: pci-generic: configurable network interface MRU richard.laing
2021-07-15 17:20 ` patchwork-bot+netdevbpf
2021-07-19 10:11 ` Loic Poulain
2021-07-19 21:44   ` Richard Laing [this message]
2021-07-27  9:21     ` Loic Poulain
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=5165a859-1b00-e50e-985e-25044cf0e9ec@alliedtelesis.co.nz \
    --to=richard.laing@alliedtelesis.co.nz \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=netdev@vger.kernel.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).