Issue found in Armada 370: "No buffer space available" error during continuous ping

Maggie Mae Roxas maggie.mae.roxas at
Mon Dec 1 20:09:05 PST 2014

Hi Willy, Thomas,
Good day.

This is just to confirm that the patch Willy sent yesterday, patched
to 3.13.9 alone, resolves these issues:
- "No buffer space available" around 17th packet
- Low throughput on iperf as client (ie, ~130 Mbits/s on 1000 Mbits/s)
- Kernel crash

We confirmed it after quite some testing.
# Full logs at:
# as iperf client:
# as iperf server:

Thank you very much for your assistance again!!! :)

Maggie Roxas

On Mon, Dec 1, 2014 at 6:15 PM, Maggie Mae Roxas
<maggie.mae.roxas at> wrote:
> Hi Thomas, Willy.
> Good day.
> Thank you for your assistance as always.
> We are currently testing the attached patch + 3.13.9.
> We'll let you know the results as soon as we've conducted enough tests
> - latest tomorrow.
> Will keep you posted.
> Regards,
> Maggie Roxas
> On Mon, Dec 1, 2014 at 5:58 PM, Willy Tarreau <w at> wrote:
>> Hi Thomas,
>> On Mon, Dec 01, 2014 at 10:32:21AM +0100, Thomas Petazzoni wrote:
>>> If I understood correctly, on RX the interrupt coalescing can be done
>>> every X packets, or after N milliseconds. However, on TX, it's only
>>> after Y packets, there is no way to configure a delay.
>> That was my understanding of the datasheet as well.
>>> But in any case, with NAPI implemented in software, are these hardware
>>> interrupt coalescing features very important? As soon as the number of
>>> interrupts becomes high, the kernel will disable the interrupt and
>>> switch to polling, no?
>> Absolutely, but despite this, the interrupts still impact the system's
>> performance, because instead of waking up the driver once the Tx queue
>> is about to be empty (let's say twice per Tx queue), we wake up as often
>> as the system supports it. The net effect is a performance loss of about
>> 5% on small packets, which is not huge of course, but would rather be
>> spent doing some more useful stuff.
>> Uri gave me a contact at Marvell who knows this device well, I'll ask
>> him if there's no other way to work with this chip. Sending an interrupt
>> at least when the Tx queue is empty would be nice :-/
>> Best regards,
>> Willy

More information about the linux-arm-kernel mailing list