Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     Christian Eggers <ceggers@arri.de>, Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Kurt Kanzenbach <kurt@linutronix.de>
Cc:     "David S . Miller" <davem@davemloft.net>,
        Woojung Huh <woojung.huh@microchip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20201016200226.23994-1-ceggers@arri.de>
From:   Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH 0/3] net: dsa: move skb reallocation to dsa_slave_xmit
Message-ID: <9795d523-c296-cc18-4188-9214fb9cc25d@gmail.com>
Date:   Fri, 16 Oct 2020 19:44:37 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Firefox/78.0 Thunderbird/78.3.2
MIME-Version: 1.0
In-Reply-To: <20201016200226.23994-1-ceggers@arri.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 10/16/2020 1:02 PM, Christian Eggers wrote:

[snip]

> On Friday, 16 October 2020, 20:03:11 CEST, Jakub Kicinski wrote:
>> FWIW if you want to avoid the reallocs you may want to set
>> needed_tailroom on the netdev.
> I haven't looked for this yet. If this can really solve the tagging AND
> padding problem, I would like to do this in a follow up patch.

The comment in netdevice.h says:

    *      @needed_headroom: Extra headroom the hardware may need, but 
not in all
    *                        cases can this be guaranteed
    *      @needed_tailroom: Extra tailroom the hardware may need, but 
not in all
    *                        cases can this be guaranteed. Some cases 
also use
    *                        LL_MAX_HEADER instead to allocate the skb

and while I have never seen a reallocation occur while pushing a 
descriptor status block in front of a frame on transmit after setting 
the correct needed_headroom, it was not exercised in a very complicated 
way either, just TCP or UDP over IPv4 or IPv6. This makes me think that 
the comment is cautionary about more complicated transmit scenarios with 
stacked devices, tunneling etc.

> 
> Wishing a nice weekend for netdev.

Likewise!
-- 
Florian