Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Thu, 2 Nov 2023 12:48:13 +0200
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Linus Walleij <linus.walleij@linaro.org>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size
Message-ID: <20231102104813.qyzkfpbwz4kiloez@skbuf>
References: <CACRpkdYg8hattBC1esfh3WBNLZdMM5rLWhn4HTRLMfr2ubbzAA@mail.gmail.com>
 <20231030152325.qdpvv4nbczhal35c@skbuf>
 <20231030153057.3ofydbzh7q2um3os@skbuf>
 <20231030-fix-rtl8366rb-v2-1-e66e1ef7dbd2@linaro.org>
 <20231030141623.ufzhb4ttvxi3ukbj@skbuf>
 <CACRpkdYg8hattBC1esfh3WBNLZdMM5rLWhn4HTRLMfr2ubbzAA@mail.gmail.com>
 <20231030152325.qdpvv4nbczhal35c@skbuf>
 <20231030153057.3ofydbzh7q2um3os@skbuf>
 <CACRpkdYb6v6dpFFySSHdQ0H+KYRDNr2V4ShZTVA2A0ar_h9D=A@mail.gmail.com>
 <CACRpkdYb6v6dpFFySSHdQ0H+KYRDNr2V4ShZTVA2A0ar_h9D=A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACRpkdYb6v6dpFFySSHdQ0H+KYRDNr2V4ShZTVA2A0ar_h9D=A@mail.gmail.com>
 <CACRpkdYb6v6dpFFySSHdQ0H+KYRDNr2V4ShZTVA2A0ar_h9D=A@mail.gmail.com>
Precedence: bulk

On Tue, Oct 31, 2023 at 10:22:05PM +0100, Linus Walleij wrote:
> Hi Vladimir,
> 
> I got around to testing this too:
> 
> # ping -s 1472 192.168.1.137
> 
> The result:
> 
> SKB before padding:
> 37 (192.168.1.13skb len=1514 headroom=18 headlen=1514 tailroom=260
> mac=(18,14) net=(32,20) trans=52
> shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
> csum(0xd4ef2b1 ip_summed=0 complete_sw=0 valid=0 level=0)
> hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0
> 7): 1472 data bydev name=lan0 feat=0x0002000000005020
> tes
> sk family=2 type=3 proto=1
> 
> SKB after padding:
> skb len=1518 headroom=18 headlen=1518 tailroom=256
> mac=(18,14) net=(32,20) trans=52
> shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
> csum(0xd4ef2b1 ip_summed=0 complete_sw=0 valid=0 level=0)
> hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0
> dev name=lan0 feat=0x0002000000005020
> sk family=2 type=3 proto=1
> 
> As expected the linear SKB is 4 bytes longer in this case.

Ok, I'm not seeing anything unusual about the skb geometry in the
skb_dump() output.