Date:   Wed, 26 Jan 2022 19:49:18 -0300
From:   Luiz Angelo Daros de Luca <luizluca@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Vladimir Oltean <olteanv@...il.com>,
        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?

Thanks Florian, I'm using this that I googled ;-)

http://download.villagetelco.org/hardware/MT7620/MT7620_ProgrammingGuide.pdf
page 206?

It says:

DWORD0 31:0 SDP0 Segment Data Pointer0

DWORD1 31 DDONE DMA Done: Indicates DMA has transferred the segment
pointed to by this Tx
descriptor.
30 LS0 Last Segment0: Data pointed to by SDP0 is the last segment.
29:16 SDL0 Segment Data Length0: Segment data length for the data
pointed to by SDP0.
15 BURST When set, the scheduler cannot hand over to other Tx queues.
Should not transmit
the next packet.
14 LS1 Last Segment1: Data pointed to by SDP1 is the last segment.
13:0 SDL1 Segment Data Length1: Segment data length for the data
pointed to by SDP1.

DWORD2
31:0 SDP1 Segment Data Pointer1

DWORD3 (TXINFO)
31 ICO IP checksum offload enable
30 UCO UDP checksum offload enable
23 TCO TCP checksum offload enable
28 TSO TCP segmentation offload
27:20 FP_BMAP Forced destination port on GSW
bit[0:5]: Ports 0 to 5
bit[6]: CPU
bit[7]: PPE
FP_BMAP = 0: routing by DA
19:15 UDF User defined field
14 0 Reserved
13 0 Reserved
12 INSP Insert PPPoE header
11:8 SIDX PPPoE session index
7 INSV Insert VLAN tag
6:4 VPRI VLAN priority tag to be inserted
3:0 VIDX VLAN ID index

It looks like st->txd.txd4 is DWORD3. There is nothing too useful for
pointing L3 headers. The remaining bits are about vlan and pppoe
offload (and forcing the forwarding port).
There are those two segment 0 and 1 data pointers and their size in
txd{1,2,3} that I don't understand how it works (yet), but I guess
that is not what we are looking for.

There are also some offload settings at CDMA (page 217), but it is
simply an enable bit. (And I don't know what CDMA or GDMA are :-/).

> > 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.

I would be perfect if the HW supported that (and I'm afraid it does not).

>
>
> >
> > 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().

Is it a 1:1 relation between tags and the DSA conduit interface (I'm
guessing this is the CPU port Ethernet device)?
Anyway, this mediatek does not seem to support multiple tags. This
patch might disable offloading when it is using any DSA tags but the
mediatek one.
I never used the NONE tag but maybe I should also exempt that tag from
disabling offloading.

diff --git a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c
b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c
index 0ae520183b..8eb5dd8721 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c
@@ -31,6 +31,7 @@
#include <linux/io.h>
#include <linux/bug.h>
#include <linux/netfilter.h>
+#include <net/dsa.h>
#include <net/netfilter/nf_flow_table.h>
#include <linux/of_gpio.h>
#include <linux/gpio.h>
@@ -788,6 +789,27 @@ err_out:
       return -1;
}

+static netdev_features_t fe_features_check(struct sk_buff *skb,
+                                          struct net_device *dev,
+                                          netdev_features_t features)
+{
+       /* No point in doing any of this if neither checksum nor GSO are
+        * being requested for this frame. We can rule out both by just
+        * checking for CHECKSUM_PARTIAL
+        */
+       if (skb->ip_summed != CHECKSUM_PARTIAL)
+               return features;
+
+       if (netdev_uses_dsa(dev)) {
+               struct dsa_device_ops *tag_ops = dev->dsa_ptr->tag_ops;
+
+               if (tag_ops && (tag_ops->proto != DSA_TAG_PROTO_MTK))
+                       features &= ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK);
+       }
+
+       return features;
+}
+
static inline int fe_skb_padto(struct sk_buff *skb, struct fe_priv *priv)
{
       unsigned int len;
@@ -1523,6 +1545,7 @@ static const struct net_device_ops fe_netdev_ops = {
#ifdef CONFIG_NET_POLL_CONTROLLER
       .ndo_poll_controller    = fe_poll_controller,
#endif
+       .ndo_features_check     = fe_features_check,
};

static void fe_reset_pending(struct fe_priv *priv)

However, I still feel odd to call a function for every single packet
when the return value is exclusively dependent on a state that will
change only when the CPU port joins or leaves the DSA switch (or when
tag is changed).

Regards,

Luiz

Powered by blists - more mailing lists