netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Bianconi <lorenzo@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: ilias.apalodimas@linaro.org, brouer@redhat.com,
	netdev <netdev@vger.kernel.org>
Subject: Re: Regression in mvneta with XDP patches
Date: Mon, 11 Nov 2019 16:37:25 +0200	[thread overview]
Message-ID: <20191111143725.GB4197@localhost.localdomain> (raw)
In-Reply-To: <20191111134615.GA8153@lunn.ch>

[-- Attachment #1: Type: text/plain, Size: 3790 bytes --]

> Hi Lorenzo, Jesper, Ilias
> 

Hi Andrew,

> I just found that the XDP patches to mvneta have caused a regression.
> 
> This one breaks networking:
> 
> commit 8dc9a0888f4c8e27b25e48ff1b4bc2b3a845cc2d (HEAD)
> Author: Lorenzo Bianconi <lorenzo@kernel.org>
> Date:   Sat Oct 19 10:13:23 2019 +0200
> 
>     net: mvneta: rely on build_skb in mvneta_rx_swbm poll routine
>     
>     Refactor mvneta_rx_swbm code introducing mvneta_swbm_rx_frame and
>     mvneta_swbm_add_rx_fragment routines. Rely on build_skb in oreder to
>     allocate skb since the previous patch introduced buffer recycling using
>     the page_pool API.
>     This patch fixes even an issue in the original driver where dma buffers
>     are accessed before dma sync.
>     mvneta driver can run on not cache coherent devices so it is
>     necessary to sync DMA buffers before sending them to the device
>     in order to avoid memory corruptions. Running perf analysis we can
>     see a performance cost associated with this DMA-sync (anyway it is
>     already there in the original driver code). In follow up patches we
>     will add more logic to reduce DMA-sync as much as possible.
> 
> I'm using an Linksys WRT1900ac, which has an Armada XP SoC. Device
> tree is arch/arm/boot/dts/armada-xp-linksys-mamba.dts.

looking at the dts, could you please confirm mvneta is using hw or sw buffer manager
on this board? Moreover are you using DSA as well?

Regards,
Lorenzo

> 
> With this patch applied, transmit appears to work O.K. My dhcp server
> is seeing good looking BOOTP requests and replying. However what is
> being received by the WRT1900ac is bad.
> 
> 11:36:20.038558 d8:f7:00:00:00:00 (oui Unknown) > 00:00:00:00:5a:45 (oui Ethernet) Null Informati4
>         0x0000:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0030:  0000 0000 0000                           ......
> 11:36:26.924914 d8:f7:00:00:00:00 (oui Unknown) > 00:00:00:00:5a:45 (oui Ethernet) Null Informati4
>         0x0000:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x0030:  0000 0000 0000                           ......
> 11:36:27.636597 4c:69:6e:75:78:20 (oui Unknown) > 6e:20:47:4e:55:2f (oui Unknown), ethertype Unkn 
>         0x0000:  2873 7472 6574 6368 2920 4c69 6e75 7820  (stretch).Linux.
>         0x0010:  352e 342e 302d 7263 362d 3031 3438 312d  5.4.0-rc6-01481-
>         0x0020:  6739 3264 3965 3038 3439 3662 382d 6469  g92d9e08496b8-di
>         0x0030:  7274 7920 2333 2053 756e 204e 6f76 2031  rty.#3.Sun.Nov.1
>         0x0040:  3020 3136 3a31 373a 3531 2043 5354 2032  0.16:17:51.CST.2
>         0x0050:  3031 3920 6172 6d76 376c 0e04 009c 0080  019.armv7l......
>         0x0060:  100c 0501 0a00 000e 0200 0000 0200 1018  ................
>         0x0070:  1102 fe80 0000 0000 0000 eefa aaff fe01  ................
>         0x0080:  12fe 0200 0000 0200 0804 6574 6830 fe09  ..........eth0..
>         0x0090:  0012 0f03 0100 0000 00fe 0900 120f 0103  ................
>         0x00a0:  ec00 0010 0000 e3ed 5509 0000 0000 0000  ........U.......
>         0x00b0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x00c0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x00d0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
>         0x00e0:  0000 0000 0000
> 
> This actually looks like random kernel memory.
> 
>      Andrew

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2019-11-11 14:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-11 13:46 Regression in mvneta with XDP patches Andrew Lunn
2019-11-11 14:33 ` Ilias Apalodimas
2019-11-11 15:05   ` Andrew Lunn
2019-11-11 15:14     ` Lorenzo Bianconi
2019-11-11 15:45       ` Andrew Lunn
2019-11-11 15:15     ` Ilias Apalodimas
2019-11-11 14:37 ` Lorenzo Bianconi [this message]
2019-11-11 15:09   ` Andrew Lunn
2019-11-11 15:12     ` Ilias Apalodimas

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=20191111143725.GB4197@localhost.localdomain \
    --to=lorenzo@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=brouer@redhat.com \
    --cc=ilias.apalodimas@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).