<guidosarducci>
russell--: not sure if you had time for review, but the NLS fixes already merged, and I've added them to a backport PR. Would appreciate if you and nbd could confirm it looks OK: https://github.com/openwrt/openwrt/pull/4025. Thanks again.
hbug_ has joined #openwrt-devel
hbug has quit [Ping timeout: 240 seconds]
<guidosarducci>
aparcar[m]: Hi Paul, any update on the libelf conversations you mentioned before? If there are still questions/concerns probably best to review and post in my BTF PR. Cheers.
Grommish has quit [Read error: Connection reset by peer]
Grommish has joined #openwrt-devel
opal has quit [Remote host closed the connection]
opal has joined #openwrt-devel
<russell-->
guidosarducci: i'm not good on backports, since I don't build "releases" in my normal workflow
<xdarklight>
Hauke: oh, I need to fix that tonight. thanks for reporting back
Grommish has quit [Read error: Connection reset by peer]
rmilecki has joined #openwrt-devel
wvdakker has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
ashkan has quit [Ping timeout: 265 seconds]
wvdakker has quit [Quit: wvdakker]
<guidosarducci>
russell--: Fair enough. The 21.02-to-master delta is small enough I didn't need to make changes, just repeat testing from the master PRs. I expect it's all OK, but any suggestions for testing or corner cases would be welcome.
<ynezz>
xback: FYI there is WIP of imx split into subtargets https://git.openwrt.org/?p=openwrt/staging/pepe2k.git in order to support cortexa7 imx6 cores
<aparcar[m]>
guidosarducci okay please convince stintel to merge it *hide*
<stintel>
hey I approved it, just wait for the 2nd approval and merge it yourself ;)
Borromini has quit [Quit: Lost terminal]
<aparcar[m]>
well I got sort of a disapproval from ynezz
<stintel>
1 disapproval isn't the end of the world
<stintel>
we had a disagreement, asked for documentation about the counter proposal, got zero response, other devs liked my PR, so merged it anyway
<stintel>
people disagree
<guidosarducci>
aparcar[m]: stintel: thanks for looking over things so far. Disapproval regarding what? TBH, having folks post concerns in the PR itself would make for easier discussion, as I can't respond to something I can't see.
<stintel>
don't let it stop progress
<stintel>
especially now since we've just branched, there is room for new/experimental/maybe-even-broken stuff in master
<stintel>
if something really messes up we can revert, as we agreed in the second last meeting
<aparcar[m]>
to proceed with that we need the buildbots to use the latest docker image which contains those packages. since ynezz maintains a good chunk of them we should wait for his response
black_ant has quit [Ping timeout: 240 seconds]
ivanich has quit [Quit: Konversation terminated!]
goliath has quit [Quit: SIGSEGV]
<guidosarducci>
aparcar[m]: True. Aside from my PR, there's a general question of consistency too. I simply added build-time checks for needed host prerequisites, one of which is pre-existing, so this seems the Right Thing To Do. That it highlighted a deficiency on buildbots is a good thing IMO.
<jow>
aparcar[m]: does it increase the kernel size? If so, then nack :)
<guidosarducci>
stintel: agree with the sentiment, though that doesn't keep me from testing as thoroughly as I can. Not fun when others break things you use. :-/ (BTW, that's a nice little MCU you're getting)
<stintel>
guidosarducci: 20 of them - my first RISC-V HW as the HiFive Unmatched delivery was delayed with ~2 months :(
<jow>
and new build deps, meh
<stintel>
guidosarducci: and 100% agree with others breaking things you use, I've been complaining about that a lot recently
<stintel>
guidosarducci: but the PR seems mostly new/optional stuff so the chance for breakage is probably limited
<guidosarducci>
jow: it doesn't change the default kernel size. Enabling it, as with KALLSYMS, will add to size. Unlike KALLSYM, BTF is off by default in debug and release builds.
<jow>
well, I am very sceptic about that entire (e)BPF business atm
<guidosarducci>
stintel: BTF support came in close to the 5.4 kernel release, and by 5.10 is much more widespread.
<jow>
I won't use it, I won't ,maintain it and it appears to introduce a lot of complexities and new dependencies. So nack/neutral from me
<stintel>
I can't wait until we fully embrace it
<stintel>
BPF is hawt
<jow>
I'll complain once it starts breaking stuff
<stintel>
jow: reasonable enough
<stintel>
though I'd suggest you try getting some hands on experience with it
<stintel>
I liked what I touched so far
<jow>
so for what is that BTF stuff needed?
<jow>
for XDP?
<guidosarducci>
jow: few deps and little complexity that I see. It's simply an extra kernel debug option. It also exposed various upstream problems with cross-compilation, which I've all upstreamed.
<stintel>
XDP is one application. improved debugging/tracing/... is another
<stintel>
I will not mention firewall5 ;)
<guidosarducci>
jow: there are 2 main BPF usage tracks: packet processing (your tc and XDP hooks) and...
<guidosarducci>
jow: ... tracing/monitoring/debug, the same space that 'perf' operates in, but on steroids. BTF enables much more on the tracing side with BPF.
<jow>
and this is relevant for OpenWrt how exactly?
<jow>
I mean it took *years* to embrace DSA which is arguably a lot less complex than cross compiling object code on-target to load it into an in-kernel VM
<guidosarducci>
jow: it as relevant as 'perf', more so as being easier/featureful to use.
<stintel>
I could think of 1 thing: SQM is completely unusable for me on APU2 (which is considered powerful hw), it limits my 1Gbps uplink to maybe 160Mbps, the new, BPF-based tracing/debugging tools might be able to shed a light on "why" this happens
<stintel>
the other option is "just disable SQM"
<guidosarducci>
jow: apples and oranges. Also there's no cross-compilation on-board.
<guidosarducci>
stintel: yes, my original motivation for fixing bugs in iproute2 and better enabling BPF support in OWRT was around SQM/QOS!
<stintel>
well that's good to know
<stintel>
I am forced to disable SQM, but that means WFH videoconf is subject to wef9pj23r-9023r90-u2rt3-]9u02r3-0r23 when some other device hogs bandwidth
<jow>
load a Debian/CentOS/Gentoo and debug it there
<stintel>
I run OpenWrt on my device
<stintel>
loading Debian/CentOS/Gentoo on it for just debugging purposes makes no sense
<stintel>
if OpenWrt makes that kind of debugging difficult, maybe I should reconsider using OpenWrt at all
<guidosarducci>
stintel: that seems pretty low for an APU2. What's the UL/DL asymmetry?
<stintel>
guidosarducci: 1000/600
<stintel>
guidosarducci: no sqm -> 900/600 on speedtest.net to local node
<stintel>
guidosarducci: sqm on -> maybe 160/160
<stintel>
if I'm lucky
<jow>
Thanks for the information. I'll pass on it though
<jow>
I am sure it'll find another contributor to ack it
<guidosarducci>
stintel: nice base stats, but 320 Mbps aggregate is very, very low. So many other things could be wrong however...
<stintel>
guidosarducci: I welcome any hints to debug this
cheakoirccloud has joined #openwrt-devel
<stintel>
but I'm mostly becoming an old(ish) fart with a strong opinion but little skill
<guidosarducci>
stintel: Yeah, I can sympathize. How bad is the bloat/latentcy without SQM. Often we find with higher-speed links it's not that bad. Your videoconference comment above garbled...
<stintel>
guidosarducci: and that's not even aggregate, that's single direction testing :P
<stintel>
guidosarducci: if I'm in a videoconf and usenet starts going it's over
dangole has quit [Ping timeout: 260 seconds]
<guidosarducci>
stintel: Yikes! Worse than I thought... I assume this is configured to use CAKE with priority tiers? The videoconf/usenet conflict could be due to lack of or misconfigured prioritization. Does you CPU usage stay low through all this?
<guidosarducci>
stintel: btw, what results do you get for non-SQM speedtests (e.g. DSLreports) that measure bloat and induced latency?
plntyk has quit [Remote host closed the connection]
plntyk has joined #openwrt-devel
<stintel>
guidosarducci: I've some IKEv2 tunnels (strongSwan)
<stintel>
but the slow traffic is not going over them
<stintel>
also tried to migrate to WG but that's a horrible disaster, I though strongSwan was difficult to get reliable ... WG is ... I've no words
<stintel>
the worst I've tried since I've started using OpenVPN 20 years ago
lnslbrty has quit [Quit: ~-AmIsraelChai-~]
lnslbrty has joined #openwrt-devel
<guidosarducci>
stintel: the posted measurements were pushing all traffic through VPN/wireguard. Probably OK if you're using low bandwidth through the tunnel.
<stintel>
I will bookmark that post and pay some attention to it on Friday probably (I went from full-time to 4 days per week so I'll have time)
<stintel>
thanks
<pkgadd>
the performance limits of the apu2 are a bit surprising (considering that the CPU isn't that bad), but rather well established I think
<guidosarducci>
stintel: np, the only way to troubleshoot these things is systematically, "shotgun" approach of trying random things is popular but doesn't work.
<pkgadd>
should be even worse on xBSD
<guidosarducci>
pkgadd: well, he's seeing 4-5X lower throughput than others reported, so worrisome.
<pkgadd>
yes
<pkgadd>
I would have expected roughly a 500 MBit/s figure with sqm
<pkgadd>
+/-
<pkgadd>
and VPN shouldn't hamper it that much either, yes, it's all single-threaded, but the VPN stuff itself should 'just' hog one core, sqm another
<guidosarducci>
pkgadd: yes, at least that. So many way things can go wrong, but few ways of getting it right. :-/
<stintel>
not it's consistent, enable SQM, speed drops below 200Mbps
<stintel>
I'd love to debug that with someone who has time for it and knows what he/she's dealings with
<stintel>
someday
Samantaz has joined #openwrt-devel
SamantazFox has quit [Ping timeout: 240 seconds]
<guidosarducci>
stintel: sure, catch me one evening when both free. cheers.
<stintel>
guidosarducci: you in CEST?
<guidosarducci>
stintel: no, PST (-8ish)
<stintel>
ow
<stintel>
I'm EEST (+3)
<stintel>
we'll see, thanks for the offer already
<guidosarducci>
stintel: np, take care.
[mbm] has quit [Remote host closed the connection]