lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFSKS=OGHQpHYFTxP9n5j7BKs9+ZcLRagtziMH9TDw=Rr7Owcg@mail.gmail.com>
Date:   Mon, 25 Jan 2021 08:33:04 -0600
From:   George McCollister <george.mccollister@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Jonathan Corbet <corbet@....net>, Nishanth Menon <nm@...com>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Kishon Vijay Abraham I <kishon@...com>,
        Sekhar Nori <nsekhar@...com>,
        Lokesh Vutla <lokeshvutla@...com>, netdev@...r.kernel.org
Subject: Re: [RFC PATCH net-next 2/3] net: hsr: add DSA offloading support

On Sun, Jan 24, 2021 at 11:29 AM Vladimir Oltean <olteanv@...il.com> wrote:
>
> On Fri, Jan 22, 2021 at 09:59:47AM -0600, George McCollister wrote:
> > diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> > index f2fb433f3828..fc7e3ff11c5c 100644
> > --- a/net/dsa/slave.c
> > +++ b/net/dsa/slave.c
> > @@ -1924,6 +1924,19 @@ static int dsa_slave_changeupper(struct net_device *dev,
> >                       dsa_port_lag_leave(dp, info->upper_dev);
> >                       err = NOTIFY_OK;
> >               }
> > +     } else if (netif_is_hsr_master(info->upper_dev)) {
> > +             if (info->linking) {
> > +                     err = dsa_port_hsr_join(dp, info->upper_dev);
> > +                     if (err == -EOPNOTSUPP) {
> > +                             NL_SET_ERR_MSG_MOD(info->info.extack,
> > +                                                "Offloading not supported");
> > +                             err = 0;
> > +                     }
> > +                     err = notifier_from_errno(err);
> > +             } else {
> > +                     dsa_port_hsr_leave(dp, info->upper_dev);
> > +                     err = NOTIFY_OK;
> > +             }
> >       }
>
> How is the RedBox use case handled with the Linux hsr driver (i.e. a
> HSR-unaware SAN endpoint attached to a HSR ring)? I would expect
> something like this:
>
>                    +---------+
>                    |         |
>                    |   SAN   |
>                    |         |
>                    +---------+
>                         |
>                         |
>                         |
>  +-----------------+---------+------------------+
>  |                 |         |                  |
>  |  Your           |   swp0  |                  |
>  |  board          |         |                  |
>  |                 +---------+                  |
>  |                    |   ^                     |
>  |                    |   |                     |
>  |                    |   | br0                 |
>  |                    |   |                     |
>  |                    v   |                     |
>  |       +-----------------------------+        |
>  |       |                             |        |
>  |       |             hsr0            |        |
>  |       |                             |        |
>  |       +---------+---------+---------+        |
>  |       |         |         |         |        |
>  |       |   swp1  |  DAN-H  |  swp2   |        |
>  |       |         |         |         |        |
>  +-------+---------+---------+---------+--------+
>             |   ^               |   ^
>     to/from |   |               |   | to/from
>      ring   |   |               |   |  ring
>             v   |               v   |
>
> Therefore, aren't you interested in offloading this setup as well?
> I.e. the case where the hsr0 interface joins a bridge that also
> contains other DSA switch ports. This would be similar to the LAG
> offload recently added by Tobias.

I'm familiar with this use case but I don't currently need to support
it on products I'm working on and in fact my hardware doesn't support
it because the fourth switch port isn't brought out on the boards.
I've also never tested it in software. I suppose when an hsr is
bridged with a non-HSR switch port it would need to figure out the hsr
redundancy interfaces are on the same switch and configure the
forwarding accordingly. It's also worth noting that on switches which
don't support automatic insertion/deletion of the HSR/PRP tag (like
the ksz9477 I think) this wouldn't be possible.

If someone has hardware that supports this and wants to work with me
to add support for it I'd certainly be open to it. Adding support for
this in the future if demand arises seems like the best plan given
what I have to work with.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ