netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
Date: Mon, 30 Oct 2023 17:30:57 +0200	[thread overview]
Message-ID: <20231030153057.3ofydbzh7q2um3os@skbuf> (raw)
In-Reply-To: <20231030152325.qdpvv4nbczhal35c@skbuf>

On Mon, Oct 30, 2023 at 05:23:25PM +0200, Vladimir Oltean wrote:
> On Mon, Oct 30, 2023 at 03:37:24PM +0100, Linus Walleij wrote:
> > On Mon, Oct 30, 2023 at 3:16 PM Vladimir Oltean <olteanv@gmail.com> wrote:
> > 
> > > Could you please try to revert the effect of commit 339133f6c318 ("net:
> > > dsa: tag_rtl4_a: Drop bit 9 from egress frames") by setting that bit in
> > > the egress tag again? Who knows, maybe it is the bit which tells the
> > > switch to bypass the forwarding process.
> > 
> > I have already tried that, it was one of the first things I tried,
> > just looking over the git log and looking for usual suspects.
> > 
> > Sadly it has no effect whatsoever, the problem persists :(
> > 
> > > Or maybe there is a bit in a
> > > different position which does this. You could try to fill in all bits in
> > > unknown positions, check that there are no regressions with packet sizes
> > > < 1496, and then see if that made any changes to packet sizes >= 1496.
> > > If it did, try to see which bit made the difference.
> > 
> > Hehe now we're talking :D
> > 
> > I did something similar before, I think just switching a different bit
> > every 10 packets or so and running a persistent ping until it succeeds
> > or not.
> > 
> > I'll see what I can come up with.
> > 
> > Yours,
> > Linus Walleij
> 
> And the drop reason in ethtool -S also stays unchanged despite all the
> extra bits set in the tag? It still behaves as if the packet goes
> through the forwarding path?

Could you please place these skb_dump() calls before and after the magic
__skb_put_padto() call, for us to see if anything unexpected changes?
Maybe the socket buffers have some unusual geometry which the conduit
interface doesn't like, for some reason.

The number of skb dumps that you provide back should be even, and
ideally the first one should be the unaltered packet, to avoid confusion :)

diff --git a/net/dsa/tag_rtl4_a.c b/net/dsa/tag_rtl4_a.c
index 25238093686c..2ca189b5125e 100644
--- a/net/dsa/tag_rtl4_a.c
+++ b/net/dsa/tag_rtl4_a.c
@@ -41,18 +41,22 @@ static struct sk_buff *rtl4a_tag_xmit(struct sk_buff *skb,
 	u8 *tag;
 	u16 out;
 
-	/* Pad out to at least 60 bytes */
-	if (unlikely(__skb_put_padto(skb, ETH_ZLEN, false)))
-		return NULL;
-
 	/* Packets over 1496 bytes get dropped unless they get padded
 	 * out to 1518 bytes. 1496 is ETH_DATA_LEN - tag which is hardly
 	 * a coinicidence, and 1518 is ETH_FRAME_LEN + FCS so we define
 	 * the threshold size and padding like this.
 	 */
 	if (skb->len >= (ETH_DATA_LEN - RTL4_A_HDR_LEN)) {
+		skb_dump(KERN_ERR, skb, true);
+
 		if (unlikely(__skb_put_padto(skb, ETH_FRAME_LEN + ETH_FCS_LEN, false)))
 			return NULL;
+
+		skb_dump(KERN_ERR, skb, true);
+	} else {
+		/* Pad out to at least 60 bytes */
+		if (unlikely(__skb_put_padto(skb, ETH_ZLEN, false)))
+			return NULL;
 	}
 
 	netdev_dbg(dev, "add realtek tag to package to port %d\n",
-- 
2.34.1


  reply	other threads:[~2023-10-30 15:31 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-30  9:26 [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size Linus Walleij
2023-10-30 14:16 ` Vladimir Oltean
2023-10-30 14:37   ` Linus Walleij
2023-10-30 15:23     ` Vladimir Oltean
2023-10-30 15:30       ` Vladimir Oltean [this message]
2023-10-31 21:22         ` Linus Walleij
2023-11-02 10:48           ` Vladimir Oltean
2023-10-30 21:50   ` Linus Walleij
2023-10-30 22:20     ` Vladimir Oltean
2023-10-30 22:57       ` Linus Walleij
2023-10-30 23:09         ` Vladimir Oltean
2023-10-30 23:11           ` Linus Walleij
2023-10-31  0:37           ` Andrew Lunn
2023-10-31  3:37             ` Florian Fainelli
2023-10-31 14:06             ` Linus Walleij
2023-10-31 16:23               ` Florian Fainelli
2023-10-30 23:33         ` Vladimir Oltean
2023-10-31 14:16           ` Linus Walleij
2023-10-31 16:34             ` Vladimir Oltean
2023-10-31 19:02               ` Linus Walleij
2023-11-02 12:32                 ` Vladimir Oltean
2023-10-31 19:18             ` Luiz Angelo Daros de Luca
2023-10-31 19:27               ` Linus Walleij
2023-11-01 12:35                 ` Luiz Angelo Daros de Luca
2023-11-01 20:26                   ` Linus Walleij
2023-11-02 10:04                     ` Vladimir Oltean
2023-11-02 10:45                     ` Vladimir Oltean
2023-11-03 17:05                     ` Luiz Angelo Daros de Luca
2023-12-30  5:19                     ` Luiz Angelo Daros de Luca
2023-12-30 12:28                       ` Linus Walleij
2023-12-30 23:56                         ` Luiz Angelo Daros de Luca
2023-11-02 10:31                   ` Vladimir Oltean
2023-11-03 17:13                     ` Luiz Angelo Daros de Luca
2023-10-31 22:44   ` Linus Walleij

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=20231030153057.3ofydbzh7q2um3os@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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;
as well as URLs for NNTP newsgroup(s).