netdev - Re: [PATCH v2 net-next] net: dsa: felix: enable cut-through forwarding between ports by default

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20211125162053.t4ilul6oh6e5hxxh@skbuf>
Date:   Thu, 25 Nov 2021 18:20:53 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        UNGLinuxDriver@...rochip.com, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH v2 net-next] net: dsa: felix: enable cut-through
 forwarding between ports by default

On Thu, Nov 25, 2021 at 07:29:09AM -0800, Jakub Kicinski wrote:
> > > Obviously shooting from the hip here, but I was expecting the cut-thru
> > > update to be before the bridge reconfig if port is joining, and after
> > > if port is leaving. Do you know what I'm getting at?  
> > 
> > Yes, I know what you're getting at. But it's a bit complicated to do,
> > given the layering constraints and that cut-through forwarding is an
> > optional feature which isn't present on all devices, so I am trying to
> > keep its footprint minimal on the ocelot library.
> > 
> > What I can do is I can disable cut-through forwarding for ports that are
> > standalone (not in a bridge). I don't have a use case for that anyway:
> > the store-and-forward latency is indistinguishable from network stack
> > latency. This will guarantee that when a port joins a bridge, it has
> > cut-through forwarding disabled. So there are no issues if it happens to
> > join a bridge and its link speed is higher than anybody else: there will
> > be no packet underruns.
> 
> Hm, to make sure I understand - fixing standalone ports doesn't
> necessary address the issue of a slow standalone port joining, right?

Yeah, I think I handled it better in v3 than my initial idea here.