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
| ||
|
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
Powered by blists - more mailing lists