From patchwork Thu Nov 8 15:17:51 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "matteo.fortini@sadel.it" X-Patchwork-Id: 197851 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id E42032C0106 for ; Fri, 9 Nov 2012 02:42:19 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756200Ab2KHPmS (ORCPT ); Thu, 8 Nov 2012 10:42:18 -0500 Received: from alcapone.vm.bytemark.co.uk ([89.16.173.107]:39997 "EHLO alcapone.vm.bytemark.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752108Ab2KHPmP (ORCPT ); Thu, 8 Nov 2012 10:42:15 -0500 X-Greylist: delayed 1450 seconds by postgrey-1.27 at vger.kernel.org; Thu, 08 Nov 2012 10:42:14 EST Received: from localhost (localhost.localdomain [127.0.0.1]) by alcapone.vm.bytemark.co.uk (Postfix) with ESMTP id 96448164136; Thu, 8 Nov 2012 15:17:57 +0000 (GMT) Received: from alcapone.vm.bytemark.co.uk ([127.0.0.1]) by localhost (alcapone.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4fXQFOfU-k9; Thu, 8 Nov 2012 15:17:55 +0000 (GMT) Received: from mail.sadel.it (85-18-228-185.ip.fastwebnet.it [85.18.228.185]) by alcapone.vm.bytemark.co.uk (Postfix) with ESMTP id 2DDB3164134; Thu, 8 Nov 2012 15:17:51 +0000 (GMT) Received: from ASSP.nospam (localhost [127.0.0.1]) by mail.sadel.it (Postfix) with ESMTPA id 14BD59D798; Thu, 8 Nov 2012 16:17:47 +0100 (CET) Received: from host171-50-dynamic.33-79-r.retail.telecomitalia.it ([79.33.50.171] helo=[192.168.1.7]) by ASSP.nospam with ESMTP (ASSP 1.9); 8 Nov 2012 16:17:46 +0100 Message-ID: Date: Thu, 08 Nov 2012 16:17:51 +0100 From: "matteo.fortini@sadel.it" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: netdev@vger.kernel.org CC: Roberto Battani , nicolas.ferre@atmel.com Subject: [RFC PATCH] Bug on AT91 macb driver rx with high network traffic Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org We are testing the robustness of the driver with UDP packets of increasing length, up to the maximum allowed. We have an UDP echo server listening on an port on the AT91 board, and we send to it increasing length UDP packets, waiting for the echo reply before sending the next one. When packets get larghish, in the >40000 bytes range, we see that the server is not receiving packets anymore, so the client does not receive the reply and the test stops. Pinging the interface once resumes the test, meaning that the packet has been actually received, but the driver is waiting for an interrupt that is not coming. We traced this down to slow/missing IRQ response, and we fixed it as in the following patch, which calls napi_reschedule() before leaving the polling loop if the loop condition is still valid at the end of the polling loop, as other net drivers appear to do. We don't know if this is the perfectly right way to do it, and we'd like your opinion on this before submitting a proper patch. I added the udp_server.c and udp_client.c softwares which may be useful. Thank you in advance, Matteo Fortini sure we * get notified when new packets arrive. =================================================================== From 2d8895022a0668f6a3c1112f15ebe471db1a471e Mon Sep 17 00:00:00 2001 From: Matteo Fortini Date: Thu, 8 Nov 2012 16:12:10 +0100 Subject: [PATCH] AT91 macb: Fix lost rx packets on high rx traffic --- drivers/net/ethernet/cadence/macb.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c index 033064b..348a20f 100644 --- a/drivers/net/ethernet/cadence/macb.c +++ b/drivers/net/ethernet/cadence/macb.c @@ -522,8 +522,16 @@ static int macb_poll(struct napi_struct *napi, int budget) work_done = macb_rx(bp, budget); if (work_done < budget) { + u32 addr; + napi_complete(napi); + addr = bp->rx_ring[bp->rx_tail].addr; + + if ((addr & MACB_BIT(RX_USED))) { + netdev_warn(bp->dev, "poll: reschedule"); + napi_reschedule(napi); + } /* * We've done what we can to clean the buffers. Make