Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
Message-ID: <5b265563-9677-44ad-92bc-96bb3b09aa82@gmail.com>
Date:   Tue, 31 Oct 2023 09:23:00 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size
Content-Language: en-US
To:     Linus Walleij <linus.walleij@linaro.org>,
        Andrew Lunn <andrew@lunn.ch>
Cc:     Vladimir Oltean <olteanv@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
References: <20231030-fix-rtl8366rb-v2-1-e66e1ef7dbd2@linaro.org>
 <20231030141623.ufzhb4ttvxi3ukbj@skbuf>
 <CACRpkdaN2rTSHXDxwuS4czCzWyUkazY4Fn5vVLYosqF0=qi-Bw@mail.gmail.com>
 <20231030222035.oqos7v7sdq5u6mti@skbuf>
 <CACRpkdZ4+QrSA0+JCOrx_OZs4gzt1zx1kPK5bdqxp0AHfEQY3g@mail.gmail.com>
 <20231030230906.s5feepjcvgbg5e7v@skbuf>
 <494a8bb7-7ca1-40bd-b3a7-babeadfd88a0@lunn.ch>
 <CACRpkdZ8A-Yz-8itXzaBuLHfFLpmwGyg2gUqyNMpx3NbjR+KPA@mail.gmail.com>
From:   Florian Fainelli <f.fainelli@gmail.com>
In-Reply-To: <CACRpkdZ8A-Yz-8itXzaBuLHfFLpmwGyg2gUqyNMpx3NbjR+KPA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 10/31/23 07:06, Linus Walleij wrote:
> On Tue, Oct 31, 2023 at 1:37 AM Andrew Lunn <andrew@lunn.ch> wrote:
>> On Tue, Oct 31, 2023 at 01:09:06AM +0200, Vladimir Oltean wrote:
>>> On Mon, Oct 30, 2023 at 11:57:33PM +0100, Linus Walleij wrote:
>>>> This of course make no sense, since the padding function should do nothing
>>>> when the packet is bigger than 60 bytes.
>>>
>>> Indeed, this of course makes no sense. Ping doesn't work, or ARP doesn't
>>> work? Could you add a static ARP entry for the 192.168.1.137 IP address?
>>
>> Probably the ARP, since they are short packets and probably need the
>> padding.
> 
> It seems correct: the reason ping stops working is not that the ping
> isn't reaching the host, I can see the pin request on tcpdumps.
> 
> The reason is that the host has no idea where to send the reply.
> Because it's not getting any ARP replies.
> 
> And that is probably because the ARP replies are short and needs
> padding to ETH_ZLEN.
> 
> I notice the code is probably borrowed from tag_brcm.c which does
> exactly the same thing (ETH_ZLEN + tag). It comes with this
> explanation:
> 
>         /* The Ethernet switch we are interfaced with needs packets to
> be at
>           * least 64 bytes (including FCS) otherwise they will be
> discarded when
>           * they enter the switch port logic. When Broadcom tags are
> enabled, we
>           * need to make sure that packets are at least 68 bytes
>           * (including FCS and tag) because the length verification is
> done after
>           * the Broadcom tag is stripped off the ingress packet.
>           *
>           * Let dsa_slave_xmit() free the SKB
>           */
> 
> The switch fabric is dropping smaller packets when CPU tags
> (DSA tags) are enabled.
> 
> So is the padding to ETH_ZLEN OK or should is happen elsewhere?

This is OK IMHO because you may not always have knowledge of which 
Ethernet MAC the switch is interfaced with, and with the tagger code, 
you have a central location to address them all.

The padding should ideally be done by the Ethernet MAC, even better when 
the HW can do it on its own (as it should), because whether there is a 
switch or not, no link partner should accept runt packets (some might 
but this is not standard).
-- 
Florian