From mboxrd@z Thu Jan 1 00:00:00 1970 From: michal.simek@xilinx.com (Michal Simek) Date: Tue, 5 May 2015 20:49:53 +0200 Subject: [PATCH 02/12] net: axienet: Handle 0 packet receive gracefully In-Reply-To: <1430834264.7191.9.camel@perches.com> References: <7fb84f65a61bbe0fdb4b61a871cf4d4f7910955d.1430817941.git.michal.simek@xilinx.com> <55b3c89b3549c61d62b8440636516fd572870842.1430817941.git.michal.simek@xilinx.com> <1430834264.7191.9.camel@perches.com> Message-ID: <554910D1.1030706@xilinx.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 05/05/2015 03:57 PM, Joe Perches wrote: > On Tue, 2015-05-05 at 11:25 +0200, Michal Simek wrote: >> From: Peter Crosthwaite >> >> The AXI-DMA rx-delay interrupt can sometimes be triggered >> when there are 0 outstanding packets received. This is due >> to the fact that the receive function will greedily consume >> as many packets as possible on interrupt. So if two packets >> (with a very particular timing) arrive in succession they >> will each cause the rx-delay interrupt, but the first interrupt >> will consume both packets. >> This means the second interrupt is a 0 packet receive. >> >> This is mostly OK, except that the tail pointer register is >> updated unconditionally on receive. Currently the tail pointer >> is always set to the current bd-ring descriptor under >> the assumption that the hardware has moved onto the next >> descriptor. What this means for length 0 recv is the current >> descriptor that the hardware is potentially yet to use will >> be marked as the tail. This causes the hardware to think >> its run out of descriptors deadlocking the whole rx path. >> >> Fixed by updating the tail pointer to the most recent >> successfully consumed descriptor. > > I think some of this would be good to have as comments > in the code instead of just in the changelog. Is it really needed? If yes, no problem to add it but git blame can point you to that. Thanks, Michal From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031001AbbEESuV (ORCPT ); Tue, 5 May 2015 14:50:21 -0400 Received: from mail-bn1bon0096.outbound.protection.outlook.com ([157.56.111.96]:58208 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755655AbbEESuQ (ORCPT ); Tue, 5 May 2015 14:50:16 -0400 Authentication-Results: spf=pass (sender IP is 149.199.60.100) smtp.mailfrom=xilinx.com; vger.kernel.org; dkim=none (message not signed) header.d=none; Message-ID: <554910D1.1030706@xilinx.com> Date: Tue, 5 May 2015 20:49:53 +0200 From: Michal Simek User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Joe Perches , Michal Simek CC: , Peter Crosthwaite , =?windows-1252?Q?S=F6ren_Brinkmann?= , , John Linn , Anirudha Sarangi , , Subject: Re: [PATCH 02/12] net: axienet: Handle 0 packet receive gracefully References: <7fb84f65a61bbe0fdb4b61a871cf4d4f7910955d.1430817941.git.michal.simek@xilinx.com> <55b3c89b3549c61d62b8440636516fd572870842.1430817941.git.michal.simek@xilinx.com> <1430834264.7191.9.camel@perches.com> In-Reply-To: <1430834264.7191.9.camel@perches.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-RCIS-Action: ALLOW X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1018-21522.005 X-TM-AS-User-Approved-Sender: Yes;Yes;Yes X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:149.199.60.100;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(438002)(164054003)(199003)(189002)(377424004)(24454002)(54534003)(377454003)(479174004)(51704005)(36386004)(4001350100001)(83506001)(80316001)(19580395003)(87936001)(19580405001)(2950100001)(63266004)(62966003)(5001960100002)(92566002)(450100001)(77156002)(46102003)(5001770100001)(106466001)(54356999)(76176999)(86362001)(50466002)(50986999)(99136001)(77096005)(6806004)(107886002)(23746002)(47776003)(36756003)(65806001)(33656002)(107986001)(4001430100001)(4001450100001);DIR:OUT;SFP:1101;SCL:1;SRVR:BN1AFFO11HUB033;H:xsj-pvapsmtpgw02;FPR:;SPF:Pass;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB033; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:BN1AFFO11HUB033;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB033; X-Forefront-PRVS: 0567A15835 X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2015 18:50:10.6247 (UTC) X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.60.100];Helo=[xsj-pvapsmtpgw02] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB033 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/05/2015 03:57 PM, Joe Perches wrote: > On Tue, 2015-05-05 at 11:25 +0200, Michal Simek wrote: >> From: Peter Crosthwaite >> >> The AXI-DMA rx-delay interrupt can sometimes be triggered >> when there are 0 outstanding packets received. This is due >> to the fact that the receive function will greedily consume >> as many packets as possible on interrupt. So if two packets >> (with a very particular timing) arrive in succession they >> will each cause the rx-delay interrupt, but the first interrupt >> will consume both packets. >> This means the second interrupt is a 0 packet receive. >> >> This is mostly OK, except that the tail pointer register is >> updated unconditionally on receive. Currently the tail pointer >> is always set to the current bd-ring descriptor under >> the assumption that the hardware has moved onto the next >> descriptor. What this means for length 0 recv is the current >> descriptor that the hardware is potentially yet to use will >> be marked as the tail. This causes the hardware to think >> its run out of descriptors deadlocking the whole rx path. >> >> Fixed by updating the tail pointer to the most recent >> successfully consumed descriptor. > > I think some of this would be good to have as comments > in the code instead of just in the changelog. Is it really needed? If yes, no problem to add it but git blame can point you to that. Thanks, Michal