Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752292AbbLBFsq (ORCPT ); Wed, 2 Dec 2015 00:48:46 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:33160 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751107AbbLBFso (ORCPT ); Wed, 2 Dec 2015 00:48:44 -0500 MIME-Version: 1.0 In-Reply-To: <20151201.143047.82022857078130793.davem@davemloft.net> References: <01d101d12c46$2de43b40$89acb1c0$@samsung.com> <1448983985.25582.35.camel@edumazet-glaptop2.roam.corp.google.com> <20151201.143047.82022857078130793.davem@davemloft.net> Date: Wed, 2 Dec 2015 11:18:43 +0530 Message-ID: Subject: Re: [PATCH 3/6] net: thunderx: Increase transmit queue length From: Sunil Kovvuri To: David Miller Cc: Eric Dumazet , Pavel Fedin , Linux Netdev List , LKML , LAKML , Sunil Goutham , Sunil Goutham Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1783 Lines: 38 >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. And above i have suggested what could be done to not see this issue. But anyway for the time being I will resubmit the patch series without this patch, hope that would be okay. On Wed, Dec 2, 2015 at 1:00 AM, David Miller wrote: > From: Sunil Kovvuri > Date: Tue, 1 Dec 2015 22:00:49 +0530 > >> Increasing descriptor ring size will lead to more memory allocation. >> And what you are seeing is a memory alloc failure and doesn't seem >> to be due to this driver change. I mean it looks like the behavior >> will be same for other drivers as well. > > The driver should successfully recover from out of memory situations > and not stop RX/TX completely. > > There might be some other problem with your driver causing this. > > 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. -- 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/