[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8ce1ad39-5f57-ecff-805d-0aaca6fbd138@gmail.com>
Date: Tue, 16 May 2017 22:41:28 +0200
From: Alexander Sverdlin <alexander.sverdlin@...il.com>
To: Ryan Mallon <rmallon@...il.com>,
Lennert Buytenhek <buytenh@...tstofly.org>,
Eric Dumazet <edumazet@...gle.com>
Cc: "David S. Miller" <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Eric Dumazet <eric.dumazet@...il.com>,
Hartley Sweeten <hsweeten@...ionengravers.com>
Subject: Re: [PATCH v2 net-next 06/12] ep93xx_eth: add GRO support
Hello all,
On 15/05/17 23:02, Alexander Sverdlin wrote:
>>> I don't know if we really care about this hardware anymore (I don't),
>>> but the ep93xx platform is still listed as being maintained in the
>>> MAINTAINERS file -- adding Ryan and Hartley.
>> I no longer have any ep93xx hardware to test with, and I never looked at
>> the Ethernet, so don't know the details. I think there are still a
>> handful of users. Adding Alexander who sent an ADC support series this
>> week, who might be able to test this?
> Yes, I very much care about ep93xx code being functional :)
> I'll test the patches tomorrow.
it turns out I've used this patch two weeks long already in 4.11; but I've spent
a couple of hours now torturing the new driver and was not able to provoke
any inadequate behavior. It either receives all packets in time or not at all.
If IRQs would be edge-triggered, I'd expect some stale packets, which do not
arrive at first, but then appear with the packets coming next. This is not
the case. I've used pktgen module for this, with minimal packets and
different bursts.
netperf shows 45Mbit/s on UDP_STREAM test, which is also fair amount for
200MHz CPU.
So, I see no problems with the change.
--
Alexander.
Powered by blists - more mailing lists