Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933487AbbLBRbJ (ORCPT ); Wed, 2 Dec 2015 12:31:09 -0500 Received: from shards.monkeyblade.net ([149.20.54.216]:45132 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933439AbbLBRbF (ORCPT ); Wed, 2 Dec 2015 12:31:05 -0500 Date: Wed, 02 Dec 2015 12:31:03 -0500 (EST) Message-Id: <20151202.123103.122030174756190808.davem@davemloft.net> To: sunil.kovvuri@gmail.com Cc: eric.dumazet@gmail.com, p.fedin@samsung.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Sunil.Goutham@caviumnetworks.com, sgoutham@cavium.com Subject: Re: [PATCH 3/6] net: thunderx: Increase transmit queue length From: David Miller In-Reply-To: References: <20151201.143047.82022857078130793.davem@davemloft.net> X-Mailer: Mew version 6.6 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 02 Dec 2015 09:31:05 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1142 Lines: 26 From: Sunil Kovvuri Date: Wed, 2 Dec 2015 11:18:43 +0530 >>The driver should successfully recover from out of memory situations >> and not stop RX/TX completely. > This memory allocation is while interface bringup/initialization and not during > packet I/O. > >>Don't put this off as not "related" to your patch, it is as this >>introduces the behavior for this user, and you should fix it before >>expecting me to apply this patch series. > I would disagree on this, as this patch hasn't introduced any failure here, > if this user has connected any device which asks for a bit large amount > of coherent memory then i am sure he will see the same issue. It's not the memory allocation that's the problem. It's the the device completely dies and does not recover even when memory does become available later. That is a hard regression which this change introduces. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/