From: Andrew Lunn <andrew@lunn.ch>
To: Felix Fietkau <nbd@nbd.name>
Cc: Vladimir Oltean <olteanv@gmail.com>,
Sean Wang <sean.wang@mediatek.com>,
Landen Chao <Landen.Chao@mediatek.com>,
DENG Qingfang <dqfext@gmail.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
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>,
Matthias Brugger <matthias.bgg@gmail.com>,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] net: dsa: tag_mtk: add padding for tx packets
Date: Thu, 12 May 2022 14:39:09 +0200 [thread overview]
Message-ID: <Ynz/7Wh6vDjR7ljs@lunn.ch> (raw)
In-Reply-To: <0ef1e0c2-1623-070d-fbf5-e7f09fc199ca@nbd.name>
Hi Felix
Thanks for the additional testing.
> I just ran some more tests, here's what I found:
> The switch automatically pads all forwarded packets to 64 bytes.
> When packets are forwarded from one external port to another, the padding is
> all zero.
> Only when packets are sent from a CPU port to an external port, the last 4
> bytes contain garbage. The garbage bytes are different for every packet, and
> I can't tell if it's leaking contents of previous packets or what else is in
> there.
> Based on that, I'm pretty sure that the hardware simply has a quirk where it
> does not account for the special tag when generating its own padding
> internally.
This does not yet explain why your receiver is dropping the frame. As
Vladimir pointed out, the contents of the pad should not matter.
Is it also getting the FCS wrong when it pads? That would cause the
receiver to drop the frame.
Or do we have an issue in the receiver where it is looking at the
contents of the pad?
Andrew
next prev parent reply other threads:[~2022-05-12 12:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 9:40 Felix Fietkau
2022-05-10 12:37 ` Vladimir Oltean
2022-05-10 14:52 ` Felix Fietkau
2022-05-10 16:52 ` Vladimir Oltean
2022-05-10 22:06 ` Felix Fietkau
2022-05-10 22:21 ` Vladimir Oltean
2022-05-11 8:50 ` Felix Fietkau
2022-05-11 9:32 ` Vladimir Oltean
2022-05-11 12:24 ` Felix Fietkau
2022-05-11 13:22 ` Vladimir Oltean
2022-05-11 14:32 ` Andrew Lunn
2022-05-12 8:51 ` Felix Fietkau
2022-05-12 12:39 ` Andrew Lunn [this message]
2022-05-12 13:08 ` Felix Fietkau
2022-05-12 15:32 ` Andrew Lunn
2022-05-11 14:39 ` Andrew Lunn
2022-05-10 21:26 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Ynz/7Wh6vDjR7ljs@lunn.ch \
--to=andrew@lunn.ch \
--cc=Landen.Chao@mediatek.com \
--cc=davem@davemloft.net \
--cc=dqfext@gmail.com \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=sean.wang@mediatek.com \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome