[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ab52cf7-e340-ff0b-4352-f18dcb9e0e6b@gmail.com>
Date: Mon, 13 Aug 2018 11:57:45 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: "Lad, Prabhakar" <prabhakar.csengg@...il.com>,
Andrew Lunn <andrew@...n.ch>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: [Query]: DSA Understanding
On 08/13/2018 08:58 AM, Lad, Prabhakar wrote:
> Hi Andrew/Florain,
>
> On Mon, Aug 13, 2018 at 2:38 PM Andrew Lunn <andrew@...n.ch> wrote:
>>
>>>> I agree, this should be padding packets correctly, can you still
>>>> instrument cpsw to make sure that what comes to its ndo_start_xmit() is
>>>> ETH_ZLEN + tag_len or more?
>>>>
>>> Yes I can confirm the skb->len is always >= 62 (ETH_ZLEN + 2)
>>
>> Which switch are you using?
>>
>> Marvell switches use either 4 or 8 bytes of tag. Broadcom has 4, KSZ
>> has 1 for packets going to the switch, lan9303 has 4, mtd uses 4, qca
>> has 2.
>>
> I am using the KSZ switch. for Ingress it has 1 byte and for Egress it
> has 2 bytes.
> I came across patch [1] and padded 2 more bytes in ksz_xmit() and I was
> successfully able to ping from lan4 to PC. Thank you very much for
> your guidance/support.
>
> Now I have stumbled into a different issue:
>
> Case 1 Works:
> =================
> lan0 = 192.168.0.1
> PC1 = 192.168.0.10
> For the above ping works from both directions.
>
> CASE 2 Doesn’t Work:
> =========================
> lan0 = 192.168.0.1
> PC1 = 192.168.0.10
> lan4 = 192.168.0.4
> PC2 = 192.168.0.11
>
> Ping from lan0 to PC1 and PC1 to lan0 works
> But ping from PC2 to lan4 and lan4 to PC2 fails.
>
> CASE 3 Works:
> =========================
> lan0 = 192.168.0.1
> PC1 = 192.168.0.10
> lan4 = 192.168.4.4
> PC2 = 192.168.4.11
>
> With the above setup ping works.
>
> [Query] Why does ping fail in case 2. Any thoughts what I am missing here ?
> or is it the expected behaviour ?
For case 2, what I suspect is happening is that the machine that has
lan1/lan4, because you have put lan1/lan4 in the same subnet, does not
know how to respond to PC2 because it is unable to select an appropriate
output interface. In such cases, you might have to add an explicit /32
route that forces telling the kernel that PC2 is accessible via lan2.
Andrew, do you see an other explanation for that?
>
> [1] https://lore.kernel.org/patchwork/patch/851457/
This patch works, but I think it is still working by "accident" in that
if you have both VLAN tags + KSZ tag, you would likely still be too
short by a few bytes.
--
Florian
Powered by blists - more mailing lists