Re: [PATCH 0/2] meson: Fix IRQ trigger type

[Jerome Brunet <jbrunet@baylibre.com>]

On Fri, 2018-12-07 at 19:28 +0100, Emiliano Ingrassia wrote:
> On Fri, Dec 07, 2018 at 11:49:15AM +0100, Jerome Brunet wrote:
> > On Thu, 2018-12-06 at 19:51 +0100, Emiliano Ingrassia wrote:
> > > Hi Carlo,
> > > 
> > > I keep running tests with packet generator,
> > > using nload to show bandwidth usage.
> > > 
> > > Here is my test results with packet generators
> > > both running on laptop and board with rate 1 Gbps.
> > 
> > Testing in UDP is unlikely to give us clear picture of anything for this
> > sort
> > of fixes.
> > 
> 
> Why? Would you mind to explain your reasoning?

Because we have no idea why packet are lost in UDP

> 
> > All your test seems in show it the fact the Amlogic SoC usually prioritize
> > the
> > TX traffic over RX, which is something we've known about for a while.
> > 
> 
> Is that normal

Yes

> and/or acceptable?

Free software, Free world .. you are free to (try to) do something about it.

> 
> > It would be helpful if you could provide TCP figures with a traffic
> > generator
> > we can all share an inspect, such as iperf3
> > 
> > Finally, Your test do not show the original issue regarding EEE. So the
> > work
> > around we put (yes, it was never considered a solution) for it should not
> > be
> > kept IHMO. Your numbers for EEE may be due to the way the traffic is
> > generated
> > and the PHY entering LPI and taking a bit of time to exit it. Again UDP is
> > not
> > very helpful to characterize this.
> > 
> 
> Did you read my email entirely

Yes I did (and I'm starting to regret it)

> or just kidding me?

I don't know what you hope accomplish with that can, but you can be sure it
won't help.

> 
> TEST 3 clearly shows that the issue regarding EEE is still there
> with both patches applied.

TEST 3 clearly shows nothing. Once gain with Tx priority and UDP, no
conclusion can be made from your test

> 
> My comment about TEST 3 (same results as TEST 2):
> "Simple ping test from laptop to board shows a packet loss
>  of 90% and more while no packet loss achieved pinging
>  the laptop from the board."
> 
> I definitively advice against the second patch (the part regarding
> 32 bit Meson SoC).
> 
> About the first one, still no evidence that is needed on Meson8b SoC.
> And I'm saying it because I tested both patches on real hardware,
> not just guessing!

LOL. What are you trying to imply exactly ?

> 
> Furthermore, as Martin reported in one of the previous mail,
> even Amlogic's buildroot kernel uses an edge rising IRQ type
> for the Meson8b MAC.

As far any other amlogic MAC ... And I think  we pointed out that every other
dwmac users out there uses LEVEL, which makes a lot more sense and is stable.


>  Other evidence that is not so clear
> the need for the first patch on 32 bit Meson SoC.

Not an evidence at all, no difference between the 32bit and 64bit arch.



> 
> > > TEST 0: no patch applied.
> > > 
> > > 1) Start packet generator on laptop:
> > > 
> > >               | incoming traffic | outgoing traffic
> > > =====================================================
> > > nload (board) |     ~940 Mbps    |       0 Mbps
> > > -----------------------------------------------------
> > > nload (laptop)|       0 Mbps     |     ~940 Mbps
> > > =====================================================
> > > 
> > > 2) Start packet generator on board:
> > > 
> > >               | incoming traffic  | outgoing traffic
> > > ==============+===================+==================
> > > nload (board) |     ~460 Mbps     |     ~256 Mbps
> > > --------------+-------------------+------------------
> > > nload (laptop)|     ~256 Mbps     |     ~940 Mbps
> > > =====================================================
> > > 
> > > 3) Stop packet generator on laptop:
> > > 
> > >               | incoming traffic | outgoing traffic
> > > =====================================================
> > > nload (board) |       0 Mbps     |    ~940 Mbps
> > > -----------------------------------------------------
> > > nload (laptop)|       ~940 Mbps  |      0 Mbps
> > > =====================================================
> > > 
> > > 4) Restart packet generator on laptop:
> > > 
> > >               | incoming traffic | outgoing traffic
> > > =====================================================
> > > nload (board) |     ~0 Mbps      |     ~940 Mbps
> > > -----------------------------------------------------
> > > nload (laptop)|     ~940 Mbps    |     ~940 Mbps
> > > =====================================================
> > > 
> > > In the last case the "ifconfig" statistics about RX packets
> > > remain fixed which probably indicates that the incoming traffic
> > > to the board is effectively being dropped.
> > > 
> > > The eth0 interrupt counter keeps incrementing.
> > > Simple ping test works correctly.
> > > 
> > > 
> > > TEST 1: IRQ type patch applied
> > > 
> > > Same results as TEST 0.
> > > 
> > > 
> > > TEST 2: eee-broken-1000t flag removed
> > > 
> > > 1) Start packet generator on laptop:
> > > 
> > >               | incoming traffic | outgoing traffic
> > > =====================================================
> > > nload (board) |      ~3Mbps      |       0 Mbps
> > > -----------------------------------------------------
> > > nload (laptop)|       0 Mbps     |     ~940 Mbps
> > > =====================================================
> > > 
> > > 2) Start packet generator on board:
> > > 
> > >               | incoming traffic  | outgoing traffic
> > > ==============+===================+==================
> > > nload (board) |     ~0 Mbps       |     ~940 Mbps
> > > --------------+-------------------+------------------
> > > nload (laptop)|     ~940 Mbps     |     ~940 Mbps
> > > =====================================================
> > > 
> > > 3) Stop packet generator on laptop:
> > > 
> > >               | incoming traffic | outgoing traffic
> > > =====================================================
> > > nload (board) |       0 Mbps     |    ~940 Mbps
> > > -----------------------------------------------------
> > > nload (laptop)|       ~940 Mbps  |      0 Mbps
> > > =====================================================
> > > 
> > > 4) Restart packet generator on laptop:
> > > 
> > >               | incoming traffic | outgoing traffic
> > > =====================================================
> > > nload (board) |     ~0 Mbps      |     ~940 Mbps
> > > -----------------------------------------------------
> > > nload (laptop)|     ~940 Mbps    |     ~940 Mbps
> > > =====================================================
> > > 
> > > In the first case the "ifconfig" statistics about RX packets
> > > are incremented consistently with the incoming traffic value
> > > showed by the nload (board side).
> > > 
> > > In the last case the "ifconfig" statistics about RX packets
> > > remain fixed which probably indicates that the incoming traffic
> > > to the board is effectively being dropped.
> > > 
> > > The eth0 interrupt counter keeps incrementing.
> > > Simple ping test from laptop to board shows a packet loss
> > > of 90% and more while no packet loss achieved pinging
> > > the laptop from the board.
> > > 
> > > 
> > > TEST 3: both patches applied.
> > > 
> > > Same results as TEST 2.
> > > 
> > > 
> > > From the results obtained from these tests,
> > > which are more accurate than the previous one,
> > > I can say that the second patch (remove eee-broken-1000t flag)
> > > should NOT be applied.
> > > 
> > > About the first one (change MAC IRQ type), I would like
> > > to do other tests with other tools like iperf3.
> > > With these results only, I would say to not apply it
> > > because nothing changed but if your stress test failed on
> > > long running and this patch fix it I would like to test it more deeply.
> > > 
> > > As final thought, the conducted tests clearly show that if the board
> > > transmits at full rate, all the incoming traffic is dropped.
> > > I think that this behaviour should be fixed but don't know if
> > > it depends on the driver or device tree description.
> > > I'll keep investigating.
> > > 
> > > Regards,
> > > 
> > > Emiliano
> > > 
> > > On Thu, Dec 06, 2018 at 04:52:28PM +0100, Emiliano Ingrassia wrote:
> > > > Hi Carlo,
> > > > 
> > > > thanks for the answer.
> > > > 
> > > > On Thu, Dec 06, 2018 at 01:17:58PM +0000, Carlo Caione wrote:
> > > > > On Thu, 2018-12-06 at 13:43 +0100, Emiliano Ingrassia wrote:
> > > > > > Hi all,
> > > > > 
> > > > > Hi Emiliano,
> > > > > 
> > > > > > thank you for involving me.
> > > > > > 
> > > > > > I applied Carlo's patches[0] on a kernel vanilla 4.19.6
> > > > > > and tested it with kernel packet generator, monitoring
> > > > > > bandwidth usage with "nload".
> > > > > > 
> > > > > > All tests were conducted on an Odroid-C1+ Rev. 0.4-20150930 board
> > > > > > with a short ethernet cable directly attached to a laptop with
> > > > > > 1G ethernet interface, with "nload" running on the board.
> > > > > > 
> > > > > > The tests I performed are composed by the following steps:
> > > > > > 
> > > > > > 1) Start packet generator with "rate 1000M" on laptop;
> > > > > > 
> > > > > > 2) Keep packet generator active on the laptop and
> > > > > >    start the packet generator on the board with "rate 1000M";
> > > > > > 
> > > > > > 3) Stop both packet generators;
> > > > > > 
> > > > > > 4) Start packet generator on the board;
> > > > > > 
> > > > > > 5) Keep packet generator active on the board and
> > > > > >    start the packet generator on the laptop.
> > > > > 
> > > > > out of curiosity: why do you expect to see something different from
> > > > > point (2)?
> > > > > 
> > > > 
> > > > I did not expect it indeed, I tried and got different results.
> > > > 
> > > > > > Test results without Carlo's patches applied:
> > > > > > 
> > > > > > 1) "nload" shows an incoming traffic of ~950Mbps;
> > > > > > 
> > > > > > 2) "nload" shows an incoming traffic of ~400Mbps
> > > > > >    and an outgoing traffic of ~250Mbps;
> > > > > > 
> > > > > > 3) "nload" shows 0Mbps both for incoming and outgoing traffic;
> > > > > > 
> > > > > > 4) "nload" shows an outgoing traffic of ~950Mbps from the board;
> > > > > > 
> > > > > > 5) "nload" shows incoming traffic of 0Mbps
> > > > > >    and an outgoing traffic of ~950Mbps.
> > > > > > 
> > > > > > Applying only the first patch (change mac IRQ type) I got the same
> > > > > > results.
> > > > > 
> > > > > This is expected. The change in the IRQ type is solving an issue
> > > > > that
> > > > > you can see if the run a stress test involving multiple components
> > > > > for
> > > > > several hours.
> > > > > 
> > > > 
> > > > OK, did you use "stress-ng" tool for tests?
> > > > 
> > > > > > Applying only the second patch (drop eee-broken-1000t) I got the
> > > > > > same
> > > > > > results!
> > > > > 
> > > > > I am a bit confused here. Wasn't the eee-broken-1000t added to fix a
> > > > > problem with the ethernet? Are you suggesting that for some reason
> > > > > you
> > > > > cannot reproduce anymore the problem for which the quirk was
> > > > > introduced?
> > > > > 
> > > > 
> > > > Problems without the "eee-broken-1000t" flags were experimented
> > > > one and a half years ago on a Amlogic development kernel from [0],
> > > > probably a 4.14 version.
> > > > Many patches about Meson8b SoC, dwmac-meson8b and dwmac driver
> > > > were introduced so yes, the "eee-broken-1000t" was added
> > > > to fix a problem with the ethernet (one and a half years ago),
> > > > but new tests are needed to say if it still necessary.
> > > > 
> > > > > > With both patches applied I got the same results but with an
> > > > > > incoming
> > > > > > traffic
> > > > > > of ~3Mbps on the board.
> > > > > 
> > > > > On all the tests and immediately from the start of the tests?
> > > > > 
> > > > 
> > > > Yes, in all the 5 steps immediately from the start.
> > > > 
> > > > I also tried to execute "nload" on both sides to see the bandwidth
> > > > usage.
> > > > 
> > > > With bot patches applied, after starting kernel packet generator
> > > > on my laptop with 1Gbps rate, "nload" on the laptop side shows me
> > > > an outgoing traffic of ~940Mbps while "nload" on the board side shows
> > > > me an incoming traffic of ~3Mbps.
> > > > 
> > > > Also consider that a pinging test from my laptop to the board shows
> > > > a packet loss of about 90%.
> > > > 
> > > > > When you hit the problem con you check in /proc/interrupts if you
> > > > > see
> > > > > the IRQ counter for the eth0 incrementing or not?
> > > > > 
> > > > 
> > > > The eth0 IRQ counter is incremented during the test.
> > > > 
> > > > > Cheers,
> > > > > 
> > > > > --
> > > > > Carlo Caione
> > > > > 
> > > > > 
> > > > 
> > > > I would like to conduct other tests with iperf3 to be sure about
> > > > the obtained results. What do you think?
> > > > Should I apply your patches on the latest Amlogic development kernel?
> > > > 
> > > > Regards,
> > > > 
> > > > Emiliano
> > > > 
> > > > [0]
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/
> > > 
> > > Cheers,
> > > 
> > > Emiliano
> > > 
> > > _______________________________________________
> > > linux-amlogic mailing list
> > > linux-amlogic@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-amlogic



_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic