netdev - Re: [PATCH v2 net-next 1/3] net: dsa: sja1105: Always send through management routes in slot 0

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 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]

Date:   Sat, 4 Jan 2020 20:42:47 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>, vivien.didelot@...il.com,
        andrew@...n.ch, davem@...emloft.net
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH v2 net-next 1/3] net: dsa: sja1105: Always send through
 management routes in slot 0



On 1/3/2020 4:37 PM, Vladimir Oltean wrote:
> I finally found out how the 4 management route slots are supposed to
> be used, but.. it's not worth it.
> 
> The description from the comment I've just deleted in this commit is
> still true: when more than 1 management slot is active at the same time,
> the switch will match frames incoming [from the CPU port] on the lowest
> numbered management slot that matches the frame's DMAC.
> 
> My issue was that one was not supposed to statically assign each port a
> slot. Yes, there are 4 slots and also 4 non-CPU ports, but that is a
> mere coincidence.
> 
> Instead, the switch can be used like this: every management frame gets a
> slot at the right of the most recently assigned slot:
> 
> Send mgmt frame 1 through S0:    S0 x  x  x
> Send mgmt frame 2 through S1:    S0 S1 x  x
> Send mgmt frame 3 through S2:    S0 S1 S2 x
> Send mgmt frame 4 through S3:    S0 S1 S2 S3
> 
> The difference compared to the old usage is that the transmission of
> frames 1-4 doesn't need to wait until the completion of the management
> route. It is safe to use a slot to the right of the most recently used
> one, because by protocol nobody will program a slot to your left and
> "steal" your route towards the correct egress port.
> 
> So there is a potential throughput benefit here.
> 
> But mgmt frame 5 has no more free slot to use, so it has to wait until
> _all_ of S0, S1, S2, S3 are full, in order to use S0 again.
> 
> And that's actually exactly the problem: I was looking for something
> that would bring more predictable transmission latency, but this is
> exactly the opposite: 3 out of 4 frames would be transmitted quicker,
> but the 4th would draw the short straw and have a worse worst-case
> latency than before.
> 
> Useless.
> 
> Things are made even worse by PTP TX timestamping, which is something I
> won't go deeply into here. Suffice to say that the fact there is a
> driver-level lock on the SPI bus offsets any potential throughput gains
> that parallelism might bring.
> 
> So there's no going back to the multi-slot scheme, remove the
> "mgmt_slot" variable from sja1105_port and the dummy static assignment
> made at probe time.
> 
> While passing by, also remove the assignment to casc_port altogether.
> Don't pretend that we support cascaded setups.
> 
> Signed-off-by: Vladimir Oltean <olteanv@...il.com>

Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
-- 
Florian