[PATCH 00/13] Switch realtek target to upstream platform

[Birger Koblitz]

Hi,

On 12.12.21 20:51, Sander Vanheule wrote:
> Hi Sebastian,
> 
> On Sun, 2021-12-12 at 12:38 +0100, Sebastian Gottschall wrote:
>>
>>> I have not experienced a single lock-up when booting with this patch, but I also
>>> didn't
>>> stress-test the machine or even used the switch part. Do you guys have more details on
>>> why
>>> it locks up, or how exactly these lock-ups can be resolved?
>> so far we found out it was related to the ethernet driver. but this is 
>> all part of the work we spended into it
>> the last months and recently again since i'm back on this projects
> 
> If it's most likely caused by the ethernet driver, then I don't think complaining about
> vsmp_smp_ops not being sufficient is appropriate here. We didn't touch the ethernet driver
> with this patch series, so any of your changes there should still apply.
It has been mentioned that it is also other parts of the interplay between SMP code, clocksource and
IRQ driver, especially for the RTL93xx. What you are proposing will likely make it much harder
to tackle this, it might even mean that we have to revert everything back out.

> 
>>>> if you do performance tests
>>>> in addition the mainline still uses 4kc as cpu architecture, which is
>>>> simply wrong for anything else but 838x
>>> Wrong or suboptimal? I don't currently experience any obvious issues, using the same
>>> toolchain for 8380, 8390 and 9300.
>> below suboptimal. i mean it decreases performance in a significant 
>> amount and fixing this issue is more than just easy
> 
> If you know since a while that this will be necessary and is an easy win, then please
> submit a patch upstream to break up the target into the SoC-families. I'd actually love to
> see things like this being submitted by you or Birger!
There is a fundamental lack of understanding here. The break-up of the families is for
OpenWRT and the way things are being built, including different configurations and code
paths for targets. So this is nothing to upstream apart from maybe some additional driver
code going there. We are trying to make OWRT do the right thing, talking about upstream
is not getting us anywhere.

>From my point of view it looks like you are trying to pull the realtek architecture
in OWRT into a direction that is based on our understanding more than 1 year ago when
stuff started to go upstream. Our understanding has fundamentally shifted with SMP and
the 93xx architectures.

> 
> Generally speaking, I don't see a reason to wait with submitting patches until other parts
> have stopped breaking. At least then we can all work from a common code base. I obviously
> prefer submitting upstream where possible, but the networking part will be mostly (or
> only) OpenWrt for a while still. People could then enjoy a continous stream of
> improvements in the snapshot builds, and might be encouraged to try writing some code
> themselves.
Indeed. A common code base. And that is moving into a completely different direction than
what you propose, based on current knowledge about the targets. If we don't have any
possibility to have different code paths plus go for GENERIC_MIPS which is likely the
wrong choice, then we essentially cut development off, because that is currently focussing
on diversifying the different architectures.

The network code is a long way away from going upstream. There is still a lot that is not
understood. From fundamentals like SMI to the right architecture of the Ethernet driver
in the face of SMP to how the SoC architectures can be put into one overall code-framework.
My point of view is that we should not be upstreaming half-baked stuff. But what is even
worse in my eyes is when we then take that half-baked stuff a year later and say: oh,
but this is the way it needs to be done now even if this no longer has anything to
do with our current understanding.

My proposal to go forward: please provide a patch to split architectures and show that
we can optimize compiler and code paths in the face of MIPS Generic for the 4 SoC
families.

Cheers,
  Birger