Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size

From: Linus Walleij
Date: Mon Oct 30 2023 - 17:50:52 EST


On Mon, Oct 30, 2023 at 3:16 PM Vladimir Oltean <olteanv@xxxxxxxxx> wrote:

> which means that here, skb->len will be 1522, if it was originally 1496.
> So the code adds 26 extra octets, and only 4 of those are legitimate (a tag).

Yeah I know :/

> The rest is absolutely unexplained, which means that until there is a
> valid explanation for them:
>
> pw-bot: cr
>
> (sorry, but if it works and we don't know why it works, then at some
> point it will break and we won't know why it stopped working)

Yeah it broke now and we don't know why...

> you said that what increments is Dot1dTpPortInDiscards. 802.1Q-2018 says
> about it: "Count of received valid frames that were discarded (i.e.,
> filtered) by the Forwarding Process." which is odd enough to me, since
> packets sent by rtl4a_tag_xmit() should *not* be processed by the forwarding
> layer of the switch, but rather, force-delivered to the specified egress
> port.

No this was a coincidence, we can rule this out. There are always
a few (2-3) Dot1dTpPortInDiscards on the switch port when it
is connected, sorry for getting this wrong :/

What happens is way more disturbing: packets are dropped
*silently* if not padded.

I added the following patch:

@@ -37,6 +37,8 @@ static struct sk_buff *rtl4a_tag_xmit(struct sk_buff *skb,
struct net_device *dev)
{
struct dsa_port *dp = dsa_slave_to_port(dev);
+ static u16 mask = BIT(6);
+ static int cnt = 0;
__be16 *p;
u8 *tag;
u16 out;
@@ -60,6 +62,19 @@ static struct sk_buff *rtl4a_tag_xmit(struct sk_buff *skb,
/* The lower bits indicate the port number */
out |= BIT(dp->index);

+ if (skb->len >= (ETH_DATA_LEN - RTL4_A_HDR_LEN)) {
+ /* Test bits... */
+ out |= mask;
+ netdev_info(dev, "add mask %04x to big package\n", mask);
+ cnt ++;
+ if (cnt == 10) {
+ cnt = 0;
+ mask <<= 1;
+ if (mask == BIT(15))
+ mask = BIT(6);
+ }
+ }
+
p = (__be16 *)(tag + 2);
*p = htons(out);

This loops over all the bits not used by the port mask and test them
one by one to see if any of them help.

Then ran a few rounds of ping -s 1472 and ping -s 1470.

There are console prints:

realtek-smi switch lan0: add mask 0040 to big package
realtek-smi switch lan0: add mask 0040 to big package
realtek-smi switch lan0: add mask 0040 to big package
(...)

Then bits 6,7,8,9,10,11,12,13,14 and 15 are tested in succession.

No error counters increase in ethtool -S lan0.

I can see the big packets leave the eth0 interface
(from ethtool -S eth0)

p05_EtherStatsPkts1024to1518Octe: 370

But they do not appear in the targeted switch port stats:

EtherStatsPkts1024to1518Octets: 22

(these 22 are some unrelated -s 1400 packets I sent to test)

Yours,
Linus Walleij