All of 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

  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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.