New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP,RFT,RFC] generic: qca8k: add experimental patch for eth mdio #4828
Conversation
+ header->data[0] = mdio_ethhdr->mdio_data; | ||
+ | ||
+ /* Get the rest of the 12 byte of data */ | ||
+ memcpy(header->data + 1, skb->data, QCA_HDR_MDIO_DATA2_LEN); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can check the cmd and skip this memcpy and the other set with write operation.
*page = regaddr & 0x3ff; | ||
} | ||
|
||
+static u16 qca8k_current_lo = 0xffff; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should consider a more safe value.... But considering the first thing will be checking the switch id... this should be fine...
@Ansuel : Hi Ansuel. Is this PR based on dsa or swconfig? I'm willing to test it but I need to know what config to use. |
it's on dsa
Il giorno ven 10 dic 2021 alle ore 22:13 rbpp ***@***.***> ha
scritto:
… @Ansuel <https://github.com/Ansuel> : Hi Ansuel. Is this PR based on dsa
or swconfig? I'm willing to test it but I need to know what config to use.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4828 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE2ZMQTBNJEEJVKSUHBSMGLUQJUQRANCNFSM5JQHBDUA>
.
|
My question was a bit foolish, qca8k has to be on dsa... Anyway, since this PR does not contain the other required changes to work on dsa (e.g., dts changes and maybe others), do I have to apply this PR together with another one of your open PRs? |
Yes sorry I rushed this and will change shortly as I'm stabilizing it with the kernel guy. |
Take your time, I'll wait for your magic! |
e32be6c
to
904ff9e
Compare
I pushed the """""""final""""""""" version of this... Hope someone can test this and give some result of stability / perf.
|
*page = regaddr & 0x3ff; | ||
} | ||
|
||
+static u16 qca8k_current_lo = 0xffff; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
qca8k_current_lo/high/page must be part of private data in structure qca8k_priv. If multiple qca8k switches does exist, currently they will share this three cached values.
The caching looks completely wrong. If we caching values, it must be done related to the registers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from the the global values that just got fixed, (still needs to be merged but i'm spending some time clearing the pr)
Caching the values looks wrong IMHO and this caching is on the regs level so we don't cache values, we cache the indirect regs used for mdio.
@Ansuel : just loaded this PR on my dumb C2600 and it's working (it's with fw3, but I don't use firewall on this AP). Any test you want me to carry? I can also test this PR on my main R7800 but I did not figure out yet how to compile a build with firewall4 in it. |
You should check port stability and CPU load with traffic. What I need to
know is if the switch stability is equal.
Il Dom 12 Dic 2021, 15:07 rbpp ***@***.***> ha scritto:
… @Ansuel <https://github.com/Ansuel> : just loaded this PR on my dumb
C2600 and it's working (it's with fw3, but I don't use firewall on this
AP). Any test you want me to carry?
I can also test this PR on my main R7800 but I did not figure out yet how
to compile a build with firewall4 in it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4828 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE2ZMQQJ255IPV65SXC7QG3UQSUCPANCNFSM5JQHBDUA>
.
|
I upgraded my R7800 with this PR and it's operational (with fw3). Bufferbloat test was not very good though but I can't tell if it's caused by this PR or by kernel 5.15. |
@rbpp do you have any stats? bufferbloat probably doesn't work as no firewall. |
Ports were stable, no drops in the logs. My C2600 was 3 days with this PR and everything looked good. As with my R7800, I used this PR only for a day because I did not want to have my main router exposed because of the problematic firewall, but it was otherwise stable during that period. |
904ff9e
to
39d9353
Compare
@rbpp was thinking, did you moved the patch to 5.15 dir or just applied this pr? Anyway the logic was wrong in the old series... I fixed it and make this more stable. Test it whatever you can :D |
d2a131b
to
fbb1562
Compare
98d3da9
to
6ee5892
Compare
@Ansuel Thank you for your work. Just one minor thing, "experimental" spelling is wrong in both the Pull Request title and one of the commits. |
@KA2107 just notice that. Anyway I'm rushing this to make it at least compliable... I need to finish a feature and I should really start refreshing all these pr... (example the add experimental patch got merged upstream and I have to backport them to 5.15) |
08f09a0
to
ad22b0c
Compare
ad22b0c
to
d973019
Compare
DSA tagger can now keep private data in the dsa switch. Backport these patch. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Add support for mdio read/write in Ethernet packet. Add support for MIB counter in Ethernet packet. Add support for phy read/write in Ethernet packet. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Add experimental patch to reduce mdio write by caching lo and hi part. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
mgmt Ethernet can read/write up to 16byte in one go. Add support for this with a new helper. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
21e0241
to
7b51f34
Compare
Anyway got this merged upstream... Will close this and include backport patches in the 5.15 pr |
Damn, completely missed the upstream discussion lately. This effectively gets you free-of-cost MIB polling. Nice job. |
@robimarko i'm still very tempted to propose the code split... wonder if they will accepted it anyway even if there isn't a user |
No way it will get accepted without a user |
Anyway I feel like this should be improved... I need to understand all the build_skb logic as it looks wrong that space is allocated and free multiple time for a packet of the same size... current problem is that with build_skb the preallocated space will be free anyway by the stmmac driver... and incrementing the users for skb seems a bit of an hack. If you have any hint about that. |
I wouldnt worry too much, as long as its freed and not leaked its fine |
it's problematic for ath79 devices as the cpu is not that fast |
It cant be that bad, its not like you have millions of packets per second for management. |
@robimarko we have tons of packet for the state machine to check the port status 100 a seconds. but i assume they can be decreased by turning off polling.. it was enabled as the cpu port can be set to base-x but never understood why they didn't just limit it to that particular mode... But I have to investigate it... could be that polling mode can be set only on switch setup and not at the mac config call |
Feature:
I need some stability testing and some perf stats.
DEPENDS
Current problem:
This slow down init. I still need to find the correct way to understand when the tagger/dsa starts to receive/send packet. Because of this every request has to timeout and use the legacy mdio way.(With the help of the kernel dev we develop a way to track when the master port (and the tagger) can correctly receive and handle packet)When the system starts to handle packet from the switch port the mdio read/write will use the Ethernet way and will be fasted.
Reason:
To support multicpu port, we probably need to enable assisted learning for cpu. This cause an increase in mdio read/write and this new way should speedup everything and remove the problem of assisted learning.
I would really appreciate any test with this.
Additions:
This also include another pr that permit to skip some redundant mdio write to reduce even more mdio use.
I should also test if we can use the same logic for the mdio read. In theory yes...
WARNING
This is not compile tested on a normal openwrt... I compiled this on linux kernel and I directly modified the source in the build dir. So expect some problem with patch apply.
I got some report that this apply directly to 5.15 pr.
@robimarko wonder if you can give some comments on the implementation if you have any idea on how this can be improved...
Signed-off-by: Ansuel Smith ansuelsmth@gmail.com