Message-ID: <ae29e4cc-c66c-ea29-b93f-c9c35d64dd66@gmail.com>
Date:   Tue, 25 Jan 2022 15:56:20 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Luiz Angelo Daros de Luca <luizluca@...il.com>,
        Vladimir Oltean <olteanv@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Frank Wunderlich <frank-w@...lic-files.de>,
        Alvin Šipraga <ALSI@...g-olufsen.dk>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "arinc.unal@...nc9.com" <arinc.unal@...nc9.com>
Subject: Re: [PATCH net-next v4 11/11] net: dsa: realtek: rtl8365mb: multiple
 cpu ports, non cpu extint



On 1/25/2022 2:29 PM, Luiz Angelo Daros de Luca wrote:
>> Could you implement a prototype of packet parsing in ndo_features_check,
>> which checks for the known DSA EtherType and clears the offload bit for
>> unsupported packets, and do some performance testing before and after,
>> to lean the argument in your favor with some numbers? I've no problem if
>> you test for the worst case, i.e. line rate with small UDP packets
>> encapsulated with the known (offload-capable) DSA tag format, where
>> there is little benefit for offloading TX checksumming.
> 
> There is no way to tell if a packet has a DSA tag only by parsing its
> content. For Realtek and Marvel EDSA, there is a distinct ethertype
> (although Marvel EDSA uses a non-registered number) that drivers can
> check. For others, specially those that add the tag before the
> ethernet header or after the payload, it might not have a magic
> number. It is impossible to securely identify if and which DSA is in
> use for some DSA tags from the packet alone. This is also the case for
> mediatek. Although it places its tag just before ethertype (like
> Realtek and Marvel), there is no magic number. It needs some context
> to know what type of DSA was applied.

Looking at mtk_eth_soc.h TX_DMA_CHKSUM is 0x7 << 29 so we set 3 bits 
there, which makes me think that either we defined too many bits, or 
some of those bits have a compounded meaning. The rest of the bits do 
not seem to be defined, so maybe there is a programmable offset where to 
calculate the checksum from and deposit it. Is there a public 
programmable manual?

> 
> skb_buf today knows nothing about the added DSA tag. Although
> net_device does know if it is a master port in a dsa tree, and it has
> a default dsa tag, with multiple switches using different tags, it
> cannot tell which dsa tag was added to that packet.
> That is the information I need to test if that tag is supported or not
> by this drive.
> 
> I believe once an offload HW can digest a dsa tag, it might support
> the same type of protocols with or without the tag.
> In the end, what really matters is if a driver supports a specific dsa tag.

To be honest, I am not sure if we need to know about the specific 
details of the tag like is it Realtek, Broadcom, Mediatek, QCA, more 
than knowing whether the L3/L4 offsets will be at "expected" locations. 
By that I mean, located at 14 bytes from the start of the frame for IP 
without VLAN , and 18 bytes with VLAN, did we "stack" switch tags on top 
of another thus moving by another X bytes etc.

> 
> Wouldn't it be much easier to have a dedicated optional
> ndo_dsa_tag_supported()? It would be only needed for those drivers
> that still use NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM and only those that
> can digest a tag.

I don't think we need to invent something new, we "just" need to tell 
the DSA conduit interface what type of switch tagger it is attached to 
and where it is in the Ethernet frame. Once we do that, the DSA conduit 
ought to be able to strip out features statically, or dynamically via 
ndo_features_check().
-- 
Florian

Powered by blists - more mailing lists