Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752606AbdLHIYX (ORCPT <rfc822;w@1wt.eu>);
        Fri, 8 Dec 2017 03:24:23 -0500
Received: from mail.free-electrons.com ([62.4.15.54]:56065 "EHLO
        mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751190AbdLHIYW (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 8 Dec 2017 03:24:22 -0500
Date: Fri, 8 Dec 2017 09:24:10 +0100
From: Antoine Tenart <antoine.tenart@free-electrons.com>
To: David Miller <davem@davemloft.net>
Cc: antoine.tenart@free-electrons.com, gregory.clement@free-electrons.com,
        thomas.petazzoni@free-electrons.com, miquel.raynal@free-electrons.com,
        nadavh@marvell.com, mw@semihalf.com, stefanc@marvell.com,
        ymarkman@marvell.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 1/6] net: mvpp2: only free the TSO header
 buffers when it was allocated
Message-ID: <20171208082410.GB4359@kwain>
References: <20171207084903.27144-1-antoine.tenart@free-electrons.com>
 <20171207084903.27144-2-antoine.tenart@free-electrons.com>
 <20171207.145329.1140922105125090186.davem@davemloft.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20171207.145329.1140922105125090186.davem@davemloft.net>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1008
Lines: 35

Hi David,

On Thu, Dec 07, 2017 at 02:53:29PM -0500, David Miller wrote:
> From: Antoine Tenart <antoine.tenart@free-electrons.com>
> Date: Thu,  7 Dec 2017 09:48:58 +0100
> 
> > This patch adds a check to only free the TSO header buffer when its
> > allocation previously succeeded.
> > 
> > Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> 
> No, please keep this as a failure to bring up.
> 
> Even if you emit a log message, it is completely unintuitive to
> have netdev features change on the user just because of a memory
> allocation failure.

OK, makes sense.

One other possibility would be to disable TSO if CMA_SIZE_MBYTES is set
to a too small value (i.e. its default). But I don't think this would be
a good solution either.

The drawback is the default configuration when selecting DMA_CMA won't
work for PPv2.

Anyway, I'll send a v2 without these patches.

Thanks!
Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com