netdev - Re: [EXT] Re: [RFC, net-next] net: qos: introduce a redundancy flow action

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: <20201120094620.5jlez4baxsnfxaur@skbuf>
Date:   Fri, 20 Nov 2020 09:46:21 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Xiaoliang Yang <xiaoliang.yang_1@....com>
CC:     Joergen Andreasen <joergen.andreasen@...rochip.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Arvid.Brodin@...n.com" <Arvid.Brodin@...n.com>,
        "m-karicheri2@...com" <m-karicheri2@...com>,
        "vinicius.gomes@...el.com" <vinicius.gomes@...el.com>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>,
        "vishal@...lsio.com" <vishal@...lsio.com>,
        "saeedm@...lanox.com" <saeedm@...lanox.com>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "idosch@...lanox.com" <idosch@...lanox.com>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "ivan.khoronzhuk@...aro.org" <ivan.khoronzhuk@...aro.org>,
        "andre.guedes@...ux.intel.com" <andre.guedes@...ux.intel.com>,
        "allan.nielsen@...rochip.com" <allan.nielsen@...rochip.com>,
        Po Liu <po.liu@....com>, Mingkai Hu <mingkai.hu@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Leo Li <leoyang.li@....com>,
        Cong Wang <xiyou.wangcong@...il.com>
Subject: Re: [EXT] Re: [RFC, net-next] net: qos: introduce a redundancy flow
 action

On Fri, Nov 20, 2020 at 09:39:12AM +0000, Xiaoliang Yang wrote:
> On 2020-11-18 3:01 Joergen Andreasen wrote:
> > I like your idea about using filter actions for FRER configuration.
> >
> > I think this is a good starting point but I think that this approach
> > will only allow us to configure end systems and not relay systems in
> > bridges/switches.
> >
> > In the following I refer to sections and figures in 802.1CB-2017.
> >
> > I am missing the following possibilities:
> > Configure split without adding an r-tag (Figure C-4 Relay system C).
> > Configure recovery without popping the r-tag (Figure C4 Relay system F).
> > Disable flooding and learning per VLAN (Section C.7).
> > Select between vector and match recovery algorithm (Section 7.4.3.4 and 7.4.3.5).
> > Configure history length if vector algorithm is used (Section 10.4.1.6).
> > Configure reset timeout (Section 10.4.1.7).
> > Adding an individual recovery function (Section 7.5).
> > Counters to be used for latent error detection (Section 7.4.4).
> >
> > I would prefer to use the term 'frer' instead of 'red' or 'redundancy'
> > in all definitions and functions except for 'redundancy-tag'.
> 
> Thanks for your suggestion, it's very useful to me. I ignored frer on
> relay system. I will study sections and features you mentioned on
> Spec. If using a new tc-frer action is ok, I will perfect and update
> it.

Is replicated IP multicast (with IGMP/MLD snooping) something that is
going to work using your current abstraction? I think this is one area
that is required to work at a higher level than the level of a physical
port.