Netdev Archive on lore.kernel.org help / color / mirror / Atom feed
From: Luiz Angelo Daros de Luca <luizluca@gmail.com> To: Vladimir Oltean <olteanv@gmail.com> Cc: "Jakub Kicinski" <kuba@kernel.org>, "Florian Fainelli" <f.fainelli@gmail.com>, "Andrew Lunn" <andrew@lunn.ch>, "Frank Wunderlich" <frank-w@public-files.de>, "Alvin Šipraga" <ALSI@bang-olufsen.dk>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "linus.walleij@linaro.org" <linus.walleij@linaro.org>, "vivien.didelot@gmail.com" <vivien.didelot@gmail.com>, "arinc.unal@arinc9.com" <arinc.unal@arinc9.com> Subject: Re: [PATCH net-next v4 11/11] net: dsa: realtek: rtl8365mb: multiple cpu ports, non cpu extint Date: Tue, 25 Jan 2022 04:15:23 -0300 [thread overview] Message-ID: <CAJq09z5JF71kFKxF860RCXPvofhitaPe7ES4UTMeEVO8LH=PoA@mail.gmail.com> (raw) In-Reply-To: <20220124223053.gpeonw6f34icwsht@skbuf> Wow... that's a lot to digest. > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> > --- > .../files/drivers/net/ethernet/ralink/mtk_eth_soc.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > 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 e07e5ed5a8f8..6ed9bc5942fd 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> > @@ -1497,6 +1498,16 @@ static int fe_change_mtu(struct net_device *dev, int new_mtu) > return fe_open(dev); > } > > +static netdev_features_t fe_features_check(struct sk_buff *skb, > + struct net_device *dev, > + netdev_features_t features) > +{ > + if (netdev_uses_dsa(dev)) > + features &= ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK); > + > + return features; > +} > + > static const struct net_device_ops fe_netdev_ops = { > .ndo_init = fe_init, > .ndo_uninit = fe_uninit, > @@ -1514,6 +1525,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) Thanks, Vladimir. I'll try that patch soon. However, it will never be accepted even in OpenWrt as is because it does offload its own proprietary tag. I might need to add another if like: > + if (netdev_uses_dsa(dev)) > + if (skb->???->proto_in_use != DSA_TAG_PROTO_MTK) > + features &= ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK); I think it would need to save the used tag in some form of an oob signal (as Florian suggested). In that case, even the netdev_uses_dsa() test can be removed as a skb with an oob tag signal is surely from a dsa device. Anyway, even with existing offload code not doing exactly what they should, they normally work given a normal device usage. The strange part is that DSA assumes those features, copied from master to slave, will still be the same even after a tag was injected into the packet. Sorry for my arrogance being a newbie but I think the place to fix the problem is still in slave feature list. It is better than having the kernel repeat the test for every single packet. And nobody will be willing to add extra overhead to a working code just because DSA needs it. It is easier to add a new function that does not touch existing code paths. I believe that those drivers with NETIF_F_HW_CSUM are fine for every type of DSA, right? So, just those with NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM set needs to be adjusted. A fully implemented ndo_features_check() will work but improving it for every driver will add extra code/overhead for all packets, used with DSA or not. And that extra code needed for DSA will either always keep or remove the same features for a given slave. I imagine that for NETIF_F_CSUM_MASK and NETIF_F_GSO_MASK, it would not be too hard to build a set of candidate packets to test if that feature is still valid after the tag was added. With that assumption, a new ndo_features_check_offline(), similar to ndo_features_check() but not be called by netif_skb_features, will test each candidate during slave setup. If the check disagrees after the tag was added, that feature should be disabled for that slave. Something like: slave->features = master->features; if (slave->features & (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM)) if (dev->netdev_ops->ndo_features_check_offline) foreach (test_candidate) tagged_test_candidate = add_tag (test_candidate, slave->tag); slave->features &= ~(master->netdev_ops->ndo_features_check_offline(test_candidate, master, slave->features) ^ master->netdev_ops->ndo_features_check_offline(tagged_test_candidate, master, slave->features) else slave->features &= ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK) The only drivers that would have performance regression while used as DSA master ports are those: 1) that does not have NETIF_F_HW_CSUM set 2) but could still offload after a particular DSA tag was added (when tag vendor and HW matches) 3) and still didn't implement the new ndo_features_check_offline(). ndo_features_check_offline() would not be too much different from what Vladmir suggested for the out-of-tree mtk_eth_soc driver. ndo_features_check_offline(sbk, dev, features) { switch (sbk->oob->tag) { case SUPPORTED_TAG_1: case SUPPORTED_TAG_2: case SUPPORTED_TAG_3: case NO_TAG: break; default: features &= ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK); } if (dev->netdev_ops->ndo_features_check) features &= dev->netdev_ops->ndo_features_check(skb, dev, features); /* some more test if needed*/ return features; } If used exclusively by DSA, ndo_features_check_offline could also be called ndo_dsa_features_check (or any better name than ndo_features_check_offline). That is not far away from what Vladmir suggested (and later retracted) in the first place. Regards, Luiz
next prev parent reply other threads:[~2022-01-25 8:46 UTC|newest] Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-05 3:15 [PATCH net-next v4 00/11] net: dsa: realtek: MDIO interface and RTL8367S Luiz Angelo Daros de Luca 2022-01-05 3:15 ` [PATCH net-next v4 01/11] net: dsa: realtek-smi: move to subdirectory Luiz Angelo Daros de Luca 2022-01-05 3:15 ` [PATCH net-next v4 02/11] net: dsa: realtek: rename realtek_smi to realtek_priv Luiz Angelo Daros de Luca 2022-01-07 3:42 ` Jakub Kicinski 2022-01-10 12:33 ` Alvin Šipraga 2022-01-16 0:04 ` Linus Walleij 2022-01-20 14:37 ` Vladimir Oltean 2022-01-05 3:15 ` [PATCH net-next v4 03/11] net: dsa: realtek: remove direct calls to realtek-smi Luiz Angelo Daros de Luca 2022-01-10 12:38 ` Alvin Šipraga 2022-01-16 0:05 ` Linus Walleij 2022-01-17 3:46 ` Florian Fainelli 2022-01-05 3:15 ` [PATCH net-next v4 04/11] net: dsa: realtek: convert subdrivers into modules Luiz Angelo Daros de Luca 2022-01-10 12:43 ` Alvin Šipraga 2022-01-17 4:02 ` Florian Fainelli 2022-01-05 3:15 ` [PATCH net-next v4 05/11] net: dsa: realtek: use phy_read in ds->ops Luiz Angelo Daros de Luca 2022-01-10 13:09 ` Alvin Šipraga 2022-01-17 4:15 ` Florian Fainelli 2022-01-18 2:55 ` Luiz Angelo Daros de Luca 2022-01-18 13:16 ` Andrew Lunn 2022-01-21 22:13 ` Luiz Angelo Daros de Luca 2022-01-21 23:48 ` Andrew Lunn 2022-01-05 3:15 ` [PATCH net-next v4 06/11] net: dsa: realtek: add new mdio interface for drivers Luiz Angelo Daros de Luca 2022-01-10 13:09 ` Alvin Šipraga 2022-01-17 4:22 ` Florian Fainelli 2022-01-18 4:38 ` Luiz Angelo Daros de Luca 2022-01-05 3:15 ` [PATCH net-next v4 07/11] net: dsa: realtek: rtl8365mb: rename extport to extint, add "realtek,ext-int" Luiz Angelo Daros de Luca 2022-01-10 13:15 ` Alvin Šipraga 2022-01-17 4:25 ` Florian Fainelli 2022-01-05 3:15 ` [PATCH net-next v4 08/11] net: dsa: realtek: rtl8365mb: use GENMASK(n-1,0) instead of BIT(n)-1 Luiz Angelo Daros de Luca 2022-01-10 13:18 ` Alvin Šipraga 2022-01-17 4:25 ` Florian Fainelli 2022-01-05 3:15 ` [PATCH net-next v4 09/11] net: dsa: realtek: rtl8365mb: use DSA CPU port Luiz Angelo Daros de Luca 2022-01-07 3:37 ` Jakub Kicinski 2022-01-10 13:22 ` Alvin Šipraga 2022-01-17 4:26 ` Florian Fainelli 2022-01-05 3:15 ` [PATCH net-next v4 10/11] net: dsa: realtek: rtl8365mb: add RTL8367S support Luiz Angelo Daros de Luca 2022-01-10 13:26 ` Alvin Šipraga 2022-01-17 4:26 ` Florian Fainelli 2022-01-05 3:15 ` [PATCH net-next v4 11/11] net: dsa: realtek: rtl8365mb: multiple cpu ports, non cpu extint Luiz Angelo Daros de Luca 2022-01-10 13:39 ` Alvin Šipraga 2022-01-10 13:53 ` Aw: " Frank Wunderlich 2022-01-11 18:17 ` Alvin Šipraga 2022-01-11 18:45 ` Aw: " Frank Wunderlich 2022-01-13 12:37 ` Alvin Šipraga 2022-01-13 15:56 ` Aw: " Frank Wunderlich 2022-01-18 4:58 ` Luiz Angelo Daros de Luca 2022-01-18 10:13 ` Alvin Šipraga 2022-01-18 13:20 ` Re: Re: " Andrew Lunn 2022-01-20 15:12 ` Vladimir Oltean 2022-01-20 23:35 ` Luiz Angelo Daros de Luca 2022-01-21 2:06 ` Vladimir Oltean 2022-01-21 3:13 ` Luiz Angelo Daros de Luca 2022-01-21 3:22 ` Florian Fainelli 2022-01-21 3:42 ` Luiz Angelo Daros de Luca 2022-01-21 3:50 ` Florian Fainelli 2022-01-21 4:37 ` Luiz Angelo Daros de Luca 2022-01-21 9:07 ` Arınç ÜNAL 2022-01-21 18:50 ` Vladimir Oltean 2022-01-21 21:51 ` Luiz Angelo Daros de Luca 2022-01-21 22:49 ` Vladimir Oltean 2022-01-22 20:12 ` Luiz Angelo Daros de Luca 2022-01-24 15:31 ` Vladimir Oltean 2022-01-24 16:46 ` Jakub Kicinski 2022-01-24 16:55 ` Vladimir Oltean 2022-01-24 17:01 ` Florian Fainelli 2022-01-24 17:21 ` Vladimir Oltean 2022-01-24 17:30 ` Florian Fainelli 2022-01-24 17:35 ` Jakub Kicinski 2022-01-24 18:20 ` Jakub Kicinski 2022-01-24 19:08 ` Vladimir Oltean 2022-01-24 19:38 ` Jakub Kicinski 2022-01-24 20:56 ` Vladimir Oltean 2022-01-24 21:42 ` Jakub Kicinski 2022-01-24 22:30 ` Vladimir Oltean 2022-01-25 7:15 ` Luiz Angelo Daros de Luca [this message] 2022-01-25 9:47 ` Vladimir Oltean 2022-01-25 22:29 ` Luiz Angelo Daros de Luca 2022-01-25 23:56 ` Florian Fainelli 2022-01-26 22:49 ` Luiz Angelo Daros de Luca 2022-01-25 9:44 ` Arınç ÜNAL 2022-01-22 15:51 ` Andrew Lunn 2022-01-30 1:54 ` Re: Re: " Luiz Angelo Daros de Luca 2022-01-30 4:42 ` Luiz Angelo Daros de Luca 2022-01-30 17:24 ` Florian Fainelli 2022-01-31 17:26 ` Luiz Angelo Daros de Luca 2022-02-01 14:46 ` Vladimir Oltean 2022-01-20 14:36 ` [PATCH net-next v4 00/11] net: dsa: realtek: MDIO interface and RTL8367S Vladimir Oltean 2022-01-20 17:46 ` Luiz Angelo Daros de Luca
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='CAJq09z5JF71kFKxF860RCXPvofhitaPe7ES4UTMeEVO8LH=PoA@mail.gmail.com' \ --to=luizluca@gmail.com \ --cc=ALSI@bang-olufsen.dk \ --cc=andrew@lunn.ch \ --cc=arinc.unal@arinc9.com \ --cc=f.fainelli@gmail.com \ --cc=frank-w@public-files.de \ --cc=kuba@kernel.org \ --cc=linus.walleij@linaro.org \ --cc=netdev@vger.kernel.org \ --cc=olteanv@gmail.com \ --cc=vivien.didelot@gmail.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: linkBe 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).