On 2018-02-15 13:29, Felix Fietkau wrote:
On 2018-02-14 16:20, Rosen Penev wrote:
On Tue, Feb 13, 2018 at 11:10 PM, Felix Fietkau <n...@nbd.name> wrote:
On 2018-02-13 23:53, Rosen Penev wrote:
Based on Qualcomm driver. Improves iperf3 throughput by ~20mbps on transmit on Archer C7v4.

Signed-off-by: Rosen Penev <ros...@gmail.com>
.../drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index 95682b7641..d32f220178 100644
--- a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c +++ b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c @@ -797,11 +797,14 @@ static netdev_tx_t ag71xx_hard_start_xmit(struct sk_buff *skb,
      if (ag71xx_has_ar8216(ag))
              ag71xx_add_ar8216_header(ag, skb);

-     if (skb->len <= 4) {
+     dma_cache_sync (NULL, skb->data, skb->len, DMA_TO_DEVICE);
The use of dma_cache_sync here makes no sense, since it's the wrong API. Also, effectively it results in the same kind of cache flush as the one
that's done by the DMA mapping done later.

From my reading of dma_cache_flush, I agree. However that's the part
of this patch that gives the biggest speedup. Before this patch, I
tested just adding that and it worked. I can back this up with
benchmarks later on.
In my test I quite often encountered big differences in throughput from
minor (and often very much unrelated) changes. I haven't found the real
source of these differences yet, so it's hard to know which changes
really help in the long run. My best guess is that some changes affect
the alignment of critical functions and thus affect the icache footprint

Exactly my impression I got when have made a mistake and jumped into this rabbit hole some time ago. Trying to port the changes QCA did I was getting random tput changes, often not logical at all. Then I started to suspect it's related to code alignment and MIPS architecture features. I realized that after I got down to (ar8327) switch port buffers and wrote few additional functions to control them. And got +50Mbps stable right away, not even touching default buffer settings.
Functions were never run, not even at switch init.

Until I see a reasonable explanation of how this change helps, I'm going to assume it's the same kind of random change fluctuation that I've seen
so often and NACK this change.

- Felix

Lede-dev mailing list

Lede-dev mailing list

Reply via email to