**** BEGIN LOGGING AT Thu Apr 08 02:59:57 2021
Apr 08 05:21:50 <Grommish> When I try to do a Package/postinst, it tries to run it at compile time.  Anyone give me a hint as to what I'm missing?  https://gist.github.com/Grommish/8ec171ec0a49187a76c7879cd89e3be8
Apr 08 05:46:05 <mangix> turns out the docker openwrt package alone is 14MB
Apr 08 05:46:16 <mangix> that is shockingly large
Apr 08 05:51:48 <mangix> wonder how much of a bad idea it is to use a flash drive as /overlay
Apr 08 05:54:19 <aparcar[m]> mangix: talk to dango, he's building a much smaller docker replacement
Apr 08 06:02:00 <Thermi> mangix: docker is written in Go and that has no dynamic libs.
Apr 08 06:02:07 <Thermi> What else did you expect?
Apr 08 06:55:00 <mangix> aparcar[m]: do tell
Apr 08 06:55:28 <mangix> Thermi: I run docker on a different host that does not run OpenWrt. Don't really pay attention to sizes there.
Apr 08 06:56:43 <mangix> lxc could be used as an alternative but that's not docker :)
Apr 08 07:20:53 <mangix> alright. make package/x/refresh is officially difficult
Apr 08 08:12:45 <dottedmag> I'm interested in building a firmware based on OpenWRT for a non-network-router device — a e-book with eInk screen. That includes a number of packages (these can go to a separate feed) and a new (actually, old resurrected) target. I'd like to keep this firmware as close to OpenWRT as possible and merge everything relevant back to OpenWRT.
Apr 08 08:13:17 <dottedmag> So, should I submit to OpenWRT support for a target that's out of scope, or should I keep it separate?
Apr 08 08:14:19 <dottedmag> The target in question is Ingenic XBurst MIPS. It was dropped from OpenWRT some time ago, and I'm not sure how useful it is here.
Apr 08 08:17:43 <paulcarroty> dottedmag, submit it for sure
Apr 08 08:22:59 <dottedmag> great, will do.
Apr 08 08:24:07 <dottedmag> The target does not have to be fully functional to be merged, right? I've got a ton of old kernel patches, so it might take some time to sort and forward-port them all.
Apr 08 08:26:37 <zorun> dottedmag, drop an email to openwrt-devel with details about the target (and how much work is likely needed to catch up), you will hopefully get more informed feedback
Apr 08 08:27:42 <dottedmag> thanks
Apr 08 08:28:00 <zorun> also, would that target have any in-tree device if merged back into openwrt? that's an important consideration
Apr 08 08:28:32 <zorun> we have limited build resources, and targets that don't have many devices tend to bit-rot much faster
Apr 08 08:32:30 <dottedmag> sorry, what's in-tree device? the device openwrt supports? No. Previous incarnation had only another e-book as subtarget, bitrot (due to stale kernel) and was removed.
Apr 08 08:33:11 <dottedmag> OTOH I can set up a CI node for making sure that at least the configuration from master builds.
Apr 08 08:33:32 <zorun> yes, the devices supported in openwrt
Apr 08 08:42:47 <paulcarroty> zorun, Github/Gitlab CI open source credits aren't an option?
Apr 08 08:44:50 <dottedmag> For a single build configuration I don't see a problem setting up a GH, GitLab, CircleCI or a privately hosted CI build - whatever turns out to be the easiest.
Apr 08 08:45:27 <dottedmag> I'll need that for full eBook image anyway.
Apr 08 08:46:52 <rmilecki> dottedmag: you should probably use "source-only" flag for such specific target
Apr 08 08:47:26 <rmilecki> dottedmag: if it doesn't go with tons of patches (making OpenWrt harder to maintain), i think it may be accepted
Apr 08 08:47:28 <paulcarroty> what's ebook we're talking about?
Apr 08 08:47:59 <rmilecki> dottedmag: FEATURES:=source-only
Apr 08 08:49:27 <dottedmag> paulcarroty: I'm resurrecting an old project of mine, OpenInkpot, and picking up the target it supported best (and HW for which I still have): https://wiki.mobileread.com/wiki/N516 - if this goes well, I'll try getting more eBooks supported.
Apr 08 08:50:08 <dottedmag> rmilecki: got it, thanks
Apr 08 08:58:50 <paulcarroty> dottedmag, cool device but ancient. something like modern kobo or kindle will be much more interesting for contributors. guess they're locked down, sadly.
Apr 08 09:00:10 <dottedmag> Old Kindles weren't - I still have a custom board that connects to a serial port in Kindle Keyboard that does not even require one to open the device.
Apr 08 09:00:17 <dottedmag> New Kindles are.
Apr 08 09:00:46 <dottedmag> I'll get to it once I have N516 running. Maybe other eBook manufacturers are not so interested in locking down their things.
Apr 08 09:22:18 <paulcarroty> dottedmag, https://blog.lidskialf.net/2021/02/08/turning-an-old-kindle-into-a-eink-development-platform/
Apr 08 09:27:49 <dottedmag> paulcarroty: Yes, that's the "old kindles". I don't think Oasis and newer populate serial port header anymore, and their upgrade process seems to be locked down.
Apr 08 09:28:07 <dottedmag> Though a nice hack to get old ones for cheap to play with :)
Apr 08 09:28:14 <dottedmag> Thank you Amazon!
Apr 08 12:30:11 <rsalvaterra> Guys, does backport-5.4/020-backport_netfilter_rtcache.patch make sense? It was never even merged upstream, it wasn't forward-ported to 5.10, and I have this faint idea that route caches were dropped in favour of RCU route lookups, quite a while ago.
Apr 08 12:39:27 <stintel> rsalvaterra: when in doubt, measure the difference?
Apr 08 12:44:26 <karlp> well, ask who committed it to that directory?
Apr 08 12:44:33 <karlp> backports are pretty explicitly meant to be backports...
Apr 08 13:07:32 <rmilecki> karlp: someone took it for a backport as it was sent for upstream inclusion
Apr 08 13:07:39 <rmilecki> but patch was rejected after all apparently
Apr 08 13:09:36 <stintel> so first we should figure out if it's still applicable / relevant for 5.10. if it is, test performance impact. if it's substantial it should be resubmitted and moved to pending-5.10 ?
Apr 08 13:11:25 <rmilecki> sounds sane
Apr 08 13:11:31 <rmilecki> testing should involve few targets
Apr 08 13:11:38 <rmilecki> and comparing with offloading probabl
Apr 08 13:16:05 <rsalvaterra> I don't know (yet, at least) how to test that, though. I stumbled upon that because I found some unused kconfig symbols.
Apr 08 13:17:20 <rsalvaterra> Namely, CONFIG_IP6_NF_QUEUE (dropped in 3.5), CONFIG_IP6_NF_TARGET_LOG (dropped in 3.4), CONFIG_IP_NF_MATCH_DSCP (dropped in 2.6.19), CONFIG_NF_CONNTRACK_IPV4 (dropped in 4.19), CONFIG_NF_CONNTRACK_IPV6 (dropped in 4.19) and CONFIG_NF_CONNTRACK_RTCACHE (which was never merged).
Apr 08 13:20:27 <rsalvaterra> stintel, rmilecki, do we really want to pay the price of that patch? It's 32 bytes *per conntrack entry* (on x86-64). Source: https://marc.info/?l=linux-netdev&m=141805298717637&w=4
Apr 08 13:21:49 <rmilecki> rsalvaterra: how can we tell without testing speed improvement first? :)
Apr 08 13:21:50 <stintel> rsalvaterra: 112 to 147 Mbps tells me yes
Apr 08 13:22:05 <rmilecki> we need more tests I believe
Apr 08 13:22:15 <rmilecki> and maybe verify if it still works at all
Apr 08 13:22:52 <rsalvaterra> rmilecki: I have my doubts it's still relevant… but without measuring, it's just handwaving.
Apr 08 13:23:53 <rmilecki> rsalvaterra: get two fast machines, connect 1 to WAN, connect one to LAN, setup IPs, make router do NAT between LAN & WAN
Apr 08 13:24:00 <rmilecki> rsalvaterra: test speed without and with patch
Apr 08 13:24:41 <stintel> no need
Apr 08 13:24:46 <stintel> rmmod the module
Apr 08 13:25:41 <stintel> and you might be able to leverage netns and test on a single machine but I've yet to get some real experience with that
Apr 08 13:25:43 <rsalvaterra> rmilecki: Not really feasible on my side… :( If someone else tests it, I won't mind do the other part of the job (backporting or dropping, depending on the result). How about it? :)
Apr 08 13:26:58 <stintel> my fast machines are using my L3/10GbE switch as GW so not super easy for me either
Apr 08 13:27:00 <stintel> hmmz
Apr 08 13:27:29 <rsalvaterra> One day, I'll have a home lab. Today isn't the day, unfortunately. :)
Apr 08 13:27:31 <stintel> oh wait, I just revived my previous box
Apr 08 13:27:39 <stintel> I can move it to a different VLAN
Apr 08 13:29:34 <rmilecki> rsalvaterra: i'll keep this patch in mind, but can't promise when I find time to test it
Apr 08 13:29:34 <rsalvaterra> stintel: Oh, I decided to go with cat.6a cabling on the new flat. Best bang for the €, at the moment… :P
Apr 08 13:30:01 <rsalvaterra> rmilecki: No worries, thanks! :)
Apr 08 13:30:24 <stintel> yeah I have some ugly 30m cat6a running next the walls :P
Apr 08 13:31:04 <stintel> but I'm way past being bothered by that
Apr 08 13:31:19 <rsalvaterra> Eheheh!
Apr 08 13:31:20 <stintel> running 7.1.2 dolby atmos in a rental apartment ...
Apr 08 13:31:33 <stintel> cables, cables everywhere!
Apr 08 13:31:57 <rsalvaterra> You're officially crazy.
Apr 08 13:32:21 <stintel> not to mention long USB cables to power ESP32/ESP8266/RPi0W's with various sensors etc :P
Apr 08 13:32:26 <rsalvaterra> I'm not going past 5.1 in a flat. Ever.
Apr 08 13:33:17 <stintel> well I went from 7.1 to 5.1.2 and that was awesome... for the few atmos sources + the amp didn't support the front height upfiring channel with DTS:X
Apr 08 13:33:49 <stintel> so I got tempted and bought a new amp that can do 7.1.2 (the previous one was choice between 7.1 or 5.1.2)
Apr 08 13:34:04 <karlp> stereo's where it's at :)
Apr 08 13:34:24 <rsalvaterra> I'm still at stereo too. :P
Apr 08 13:34:34 <stintel> actually it can do 7.2.4 but then I need 1 stereo PA extra
Apr 08 13:34:50 <stintel> which I already built (DIY kit) few weeks ago
Apr 08 13:35:04 <stintel> so now I am tempted to test front wide with the speakers from the bedroom 😂
Apr 08 13:35:08 <rsalvaterra> stintel: I'd hate to be your neighbour. :P
Apr 08 13:36:03 <stintel> well I have a duplex penthouse, the fun stuff is in the top floor, and no neighbor directly below me so there's 2 floors between me and the next
Apr 08 13:36:52 <rsalvaterra> Ah, ok, that's fine.
Apr 08 13:36:58 <stintel> and I put the sub on acoustic isolation stands, which greatly reduces the bass spreading via the walls
Apr 08 13:38:19 <stintel> ah, that reminds me I'm still waiting for my new speakers :(
Apr 08 13:40:10 <rsalvaterra> stintel: Do you use Kodi as media centre?
Apr 08 13:40:22 <stintel> rsalvaterra: what else is there ;)
Apr 08 13:40:30 <stintel> I'm using XBMC since Xbox1
Apr 08 13:40:41 <rsalvaterra> :D
Apr 08 13:40:45 <stintel> I even have the XBMC hoodie!
Apr 08 13:41:02 <stintel> the one they were selling at the time of the rebrand
Apr 08 13:41:03 <rsalvaterra> I started with OpenELEC, now I'm on LibreELEC. :P
Apr 08 13:41:19 <stintel> I'm with CoreELEC because it worked best on VIM3 at the time I got it
Apr 08 13:41:26 <stintel> but I'm not a fan of any of them
Apr 08 13:41:44 <stintel> I should continue my meson target and update my kodi for openwrt packages
Apr 08 13:42:05 <rsalvaterra> Kodi on OpenWrt? Heresy. o_O
Apr 08 13:42:27 <stintel> https://github.com/stintel/lede-wip
Apr 08 13:43:05 <rsalvaterra> *facepalm*
Apr 08 13:43:12 <stintel> rsalvaterra: https://twitter.com/stintel/status/840501146343084032
Apr 08 13:44:19 <stintel> my main problem with *ELEC is that it's read-only and can't really use it for anything else than kodi
Apr 08 13:44:26 <stintel> I'm allergic to those kind of things :P
Apr 08 13:44:34 <stintel> there's a reason I'm running OpenWrt
Apr 08 13:44:37 <rsalvaterra> Oh, I love statelessness. ;)
Apr 08 13:45:08 <rsalvaterra> But that's the whole point… It's supposed to be an appliance.
Apr 08 13:47:00 <stintel> well hence my reason for "porting" it to OpenWrt
Apr 08 13:47:32 <stintel> but there was very little interest, and some demotivating response even
Apr 08 13:47:43 <rsalvaterra> Sure, it you want to run OpenWrt on everything… :)
Apr 08 13:48:12 <stintel> OpenWrt on embedded, Gentoo on powerful stuff
Apr 08 13:50:58 <rsalvaterra> I don't know… for everything involving GPUs, I prefer to run bleeding edge kernels. 5.10 is a bit long in the tooth already.
Apr 08 13:51:41 <stintel> well all my rpi's run headless for example
Apr 08 13:55:48 <rsalvaterra> Heh… I had a 1 B+ as a print/scan server, running OpenWrt. Unfortunately I had issues with SANE (the scanner would hang if you cancelled the scan, had to unplug the USB to fix it), so I had to decommission it.
Apr 08 14:00:47 <stintel> ah I have a network printer/scanner
Apr 08 14:01:13 <stintel> that does double-sided printing in double-pass and double-sided scanning in single pass. love that thing
Apr 08 15:27:09 <rsalvaterra> Yay! My zstd-as-default patch for ubifs was accepted upstream. :) https://lore.kernel.org/linux-mtd/CAFLxGvwhtRY-6kT-sN=AgjvyssHb5qdTS6WQHkhKu3YrPuTkdw@mail.gmail.com/
Apr 08 15:27:39 <stintel> *clapclap*
Apr 08 15:28:43 * rsalvaterra is on a crusade to kill both lzo and zlib …:P
Apr 08 15:38:30 * karlp appreciates the portability of some boring traditional uncool things...
Apr 08 15:40:35 <karlp> I mean, "kill zlib" seems excessive...
Apr 08 15:42:33 <rsalvaterra> It's not killing… it's putting it out of its misery. :P
Apr 08 15:48:23 * karlp infers from the lack of alterantive c impls, and from the omitted benchmarks that program size and memory usage are not goals of zstd, and may be a reason why some people still use "useless, inferior, legacy" trash :)
Apr 08 15:51:55 <rsalvaterra> karlp: Those are configurable… If you want high compression ratios, you pay with RAM and CPU time. ;)
Apr 08 16:03:26 * ldir wants the moon on a stick - take loads of ram and inordinate amounts of cpu
Apr 08 16:35:25 <karlp> rsalvaterra: it's goign to replace things like https://github.com/atomicobject/heatshrink anytime soon though :)
Apr 08 16:35:36 <karlp> it's _not_ going to replace....
Apr 08 16:35:59 <karlp> (admittedly, not zlib either, but there's tiny zlib compatible implementations too)
Apr 08 16:41:06 <Zero_Chaos> Package iptables-nft is missing dependencies for the following libraries:
Apr 08 16:41:08 <Zero_Chaos> libiptext6.so
Apr 08 16:41:18 <Zero_Chaos> trying to build on the 21.02 branch
Apr 08 17:11:59 <rsalvaterra> karlp: Uhh… that's a library for tiny MCUs, for sure. I'm positive zstd isn't supposed to be used on 80C51 and friends… :P
Apr 08 17:14:42 <karlp> wel, zlib does get used in those places, or at least, zlib compatible :)
Apr 08 17:15:02 <karlp> so you can use the same tooling in both ends easily
Apr 08 17:15:26 <karlp> anywya, zstd is rad, no complaints, just maybe we don't need to kill zlib :)
Apr 08 17:17:37 <rsalvaterra> Oh, I don't mean killing in the general case! :)
Apr 08 18:22:22 <rsalvaterra> stintel, rmilecki, on a deeper analysis, I'm lead to believe 020-backport_netfilter_rtcache.patch is just broken.
Apr 08 18:23:01 <rsalvaterra> I see several instances of #if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6) in that patch…
Apr 08 18:23:02 <stintel> rsalvaterra: I have that module loaded on all my routers
Apr 08 18:23:38 <rsalvaterra> … CONFIG_NF_CONNTRACK_IPV6 has been dropped in Linux 4.19.
Apr 08 18:23:54 <rsalvaterra> stintel: Running which OpenWrt versions?
Apr 08 18:23:58 <stintel> rsalvaterra: master
Apr 08 18:24:50 <rsalvaterra> Well, it surely isn't doing anything for IPv6, then.
Apr 08 18:24:55 <stintel> with the strongswan breakage I noticed I haven't upgraded in a while (like 45 days) but recent enough
Apr 08 18:25:03 <stintel> rsalvaterra: does anyone use IPv6 then?
Apr 08 18:25:06 <stintel> (SCNR)
Apr 08 18:25:22 <stintel> let
Apr 08 18:25:28 <rsalvaterra> :P
Apr 08 18:25:28 <stintel> let's see if I can do that setup to test
Apr 08 18:28:13 <stintel> hmmmz should have ordered some extra Cat6a with those DACs :/
Apr 08 18:29:14 <stintel> and I need to find the sheet of paper with the VLAN/subnet convention I came up with when configuring my 10GbE switch
Apr 08 18:29:22 <stintel> welp
Apr 08 18:29:46 * rsalvaterra was very happy to know Cat.6A doesn't require special tools for termination…
Apr 08 18:30:49 <rsalvaterra> You're going to test conntrack at 10 Gb/s? Now that's torture. :P
Apr 08 18:31:05 <stintel> :D
Apr 08 18:31:15 <stintel> no no, on my spare ERL
Apr 08 18:31:24 <stintel> so that there's no influence from real traffic
Apr 08 18:36:14 <stintel> oh, I actually made an ods!
Apr 08 18:36:58 <rsalvaterra> Uh?
Apr 08 18:37:35 <stintel> open document spreadsheet (with the VLAN/subnet info)
Apr 08 18:38:28 <rsalvaterra> Ah! I was totally out of context. :P
Apr 08 18:43:56 <stintel> uhhh I wanna play with the CN6640 :(
Apr 08 18:50:00 <Grommish> rsalvaterra: I've got a 350m spool of cat6a sitting next to me :D  But i only use 2-part rj45 connectors, single piece connectors aren't worth the hassle
Apr 08 18:51:38 <Grommish> Or, can always cheat and just get a keystone jack and punch it in
Apr 08 21:20:35 <stintel> argh, been on the phone for over 2h, let's see if I can get to testing
Apr 08 21:44:04 <stintel> pffft can't even get the firewall rules straight
Apr 08 21:44:46 <rsalvaterra> Ouch… what happened? :P
Apr 08 21:46:42 <stintel> I've been using this device for trying to reproduce the horrible WG breakage, with doing that renamed some interfaces etc
Apr 08 21:47:01 <stintel> I allowed forwarding from test to wan but in fact I needed to allow from test to lan
Apr 08 21:48:22 <stintel> I should probably start documenting my network a bit
Apr 08 21:48:37 <stintel> had been eyeing netbox but overly complex imo
Apr 08 21:48:44 <stintel> I mean to maintain
Apr 08 21:48:49 <stintel> different components etc
Apr 08 21:50:00 <stintel> [  4]   0.00-10.00  sec  55.3 MBytes  46.4 Mbits/sec   30             sender
Apr 08 21:50:02 <stintel> lulz
Apr 08 21:50:27 <rsalvaterra> That's… not good… :P
Apr 08 21:50:50 <stintel> sqm :P
Apr 08 21:51:19 <stintel> now even with sqm disabled it's not good: [  4]   0.00-10.00  sec   141 MBytes   119 Mbits/sec   29             sender
Apr 08 21:51:52 <stintel> and that's with flow_offloading + rtcache
Apr 08 21:52:10 <stintel> I don't remember the ERL being *that* slow
Apr 08 21:52:22 <stintel> it's without NAT even
Apr 08 21:53:44 <stintel> ah no it's without rtcache
Apr 08 21:54:29 <stintel> modprobed it, no noticeable difference
Apr 08 21:58:40 <stintel> it seems to make a difference without flow offloading
Apr 08 22:00:10 <stintel> let me make some ascii art gist with some stats
Apr 08 22:08:25 <stintel> rsalvaterra: https://gist.github.com/stintel/299684b0b9eef896acc9746c4d8be746
Apr 08 22:10:13 <stintel> also added with flow_offload now
Apr 08 22:11:58 <stintel> so it seems to me that nf_conntrack_rtcache is useless in combination with flow offload
Apr 08 22:12:32 <stintel> and flow offload improves performance much better
Apr 08 22:13:55 <stintel> so given that + fact that nf_conntrack_rtcache  was never accepted upstream and flow_offload was ... we should probably just drop nf_conntrack_rtcache and focus on flow_offload
Apr 08 22:15:22 <stintel> ahhh and rmmod nf_conntrack_rtcache on x86/64 -> crash
Apr 08 22:15:46 <stintel> well maybe not a crash
Apr 08 22:32:57 <stintel> but I almost can't believe those speeds without rtcache and without offloading
Apr 08 22:33:00 <stintel> 35Mbps?!
Apr 08 22:33:56 <stintel> even with rtcache 65Mbps seems crazy
Apr 08 22:48:20 <stintel> 26|07:14:04< stintel> I'm doing 100/60 on EdgeRouter Lite
Apr 08 22:48:21 <stintel> 26|07:14:08< stintel> with sqm
Apr 08 22:49:11 <stintel> that was december 2016. smells like a regression. then again I have always suspected a general network regression at some point
Apr 08 22:49:17 <stintel> also with my apu2
Apr 08 22:51:06 <stintel> I can probably try some official images, wiped config, and connect the spare ERL directly to 2 physical machines to do some comparisons between older openwrt/lede releases and now
Apr 08 23:14:09 <rsalvaterra> stintel: Back, sorry for the delay.
Apr 08 23:14:39 <rsalvaterra> Heh… rmmod is mostly best-effort, I think. :P
Apr 08 23:15:45 <rsalvaterra> So, there's the reason why the rtcache patch wasn't merged. :)
Apr 08 23:17:09 <stintel> well it predates flow offload afaik, and it does improve performance
Apr 08 23:17:31 <stintel> pretty sure that's the reason we kept it
Apr 08 23:18:33 <rsalvaterra> In any case, it's probably incompatible with SQM, just like flow offloading…
Apr 08 23:19:11 <stintel> that's an interesting thought
Apr 08 23:19:26 * stintel tries speedtest without sqm and without flow offload on his main router
Apr 08 23:19:46 <rsalvaterra> Wait, you had SQM enabled?
Apr 08 23:19:56 <stintel> no no the gist is without sqm
Apr 08 23:20:07 <rsalvaterra> Phew… :P
Apr 08 23:20:10 <stintel> and on a spare ERL, not doing an real traffic
Apr 08 23:20:42 <stintel> but if disabling flow offloading shows a similar slowdown as enabling sqm on my main router ...
Apr 08 23:20:55 <stintel> which kind of looks like it
Apr 08 23:21:21 <stintel> so maybe enabling sqm just breaks flow offloading
Apr 08 23:22:18 <rsalvaterra> It does. I had some really weird latency spikes and wild throughput variability with SQM and flow offloading both enabled. Took me a while to figure out the cause.
Apr 08 23:34:55 <stintel> hmmm.. would it be awkward if I ordered another pizza just 10 minutes after the first one was delivered :P
Apr 08 23:36:02 <rsalvaterra> I don't think they're in the business of judging… :P
Apr 08 23:36:36 <stintel>     ERROR: package/feeds/routing/bird2 failed to build.
Apr 08 23:36:37 <stintel> derp
Apr 08 23:37:49 <jow> stintel: rtcache is indeed obsolete since there's upstream endorsed flow offloading
Apr 08 23:38:22 <jow> it was kind of a stop gap solution to speed up slow ar71xx/ath79
Apr 08 23:38:25 <stintel> rsalvaterra: feel like sending a patch? jow can ACK it and I can merge it ;)
Apr 08 23:38:35 <rsalvaterra> jow: Yay, thanks for the authoritative explanation. :)
Apr 08 23:38:57 <rsalvaterra> stintel: Sure, let me cook it up. Should be faster than that pizza… :P
Apr 08 23:38:58 <stintel> should we even nuke it from 21.02?
Apr 08 23:39:02 <stintel> rsalvaterra: hahaa
Apr 08 23:39:09 <jow> at some point netfilter performance nosedived with newer kernel versions
Apr 08 23:39:12 <stintel> rsalvaterra: yeah, no dr oetker in storrage :P
Apr 08 23:39:31 <rsalvaterra> Oh…
Apr 08 23:39:35 <jow> but before flow offloading existed
Apr 08 23:39:53 * rsalvaterra remembers already having bumped 5.10 to 5.10.28.
Apr 08 23:40:00 <jow> so nbd merged the rtcache stuff which never ended up upstream
Apr 08 23:40:17 <stintel> I might do some effort tomorrow to rip out the spare ERL from my rack, throw it between two beefy physical machines, and do some proper testing with default config
Apr 08 23:40:59 <stintel> I'm no longer working full time, so I should have some more time for OSS, but will try to spread it between that and life
Apr 08 23:42:14 <jow> as for flow offloading and sqm/qos... isn't that conflicting goals by definition?
Apr 08 23:42:27 <jow> flow offloading is essentially kernel subsystem bypassing for most packets
Apr 08 23:42:41 <jow> so no wonder stuff can't mangle these properly anymore
Apr 08 23:43:15 <rsalvaterra> jow: Yes, especially when the SQM flow dissector does NAT lookups… :P
Apr 08 23:43:56 <rsalvaterra> The connection still "works", but the performance is all over the place.
Apr 08 23:45:25 <philipp64> how do you fail out of a init.d script that uses procd if you find a broken configuration?
Apr 08 23:47:37 <jow> philipp64: one way is using procd_set_param error "whatever"
Apr 08 23:47:59 <jow> this will still submit the service state to procd and register it, but procd will nto launch the process and indicate the errors in syslog instead
Apr 08 23:48:06 <philipp64> how does that affect the flow of execution? does that return?
Apr 08 23:48:14 <karlp> I've always just returned before procd_open_service.
Apr 08 23:48:23 <jow> yes, it will return like any other call
Apr 08 23:48:39 <jow> the other way is what karlp said, just don't submit the service
Apr 08 23:49:40 <jow> means avoid calling procd_open_service or procd_open_instance (which implies procd_open_service)
Apr 08 23:50:03 <jow> so essentially "return" before that point is reached
Apr 08 23:50:30 <rsalvaterra> stintel: Refreshing the kernel patches (after deleting the rtcache patch)…
Apr 08 23:51:39 <jow> time to hit the bed. bbl
Apr 08 23:52:24 <guidosarducci> stintel: hey there, still seeing that weird perf behaviour w/wo sqm?
Apr 08 23:53:15 <stintel> jow: nn!
Apr 08 23:53:27 <stintel> guidosarducci: well yeah
Apr 08 23:53:52 <stintel> guidosarducci: I don't have a super reliable way to test (speedtest.net), but it's pretty consistently much slower with SQM enabled
Apr 08 23:54:12 <stintel> guidosarducci: but haven't done more debugging/reading/experimenting since you threw me that forum link
Apr 08 23:56:04 <stintel> ~745/605 w/o SQM and ~477/205 w/ SQM
Apr 08 23:56:27 <stintel> but as I said, it's using speedtest.net (to a server of my own ISP though)
Apr 08 23:57:16 * stintel tries to find that forum post in his 200 browser tabs :/\
Apr 08 23:58:12 <rsalvaterra> stintel: You've got mail. :P
Apr 08 23:59:44 <stintel> I noticed :p
Apr 08 23:59:57 <stintel> too bed jow hit the sack already
Apr 09 00:00:23 <rsalvaterra> No rush… 5.4 is going the way of the dodo, anyway… XD
Apr 09 00:00:28 <stintel> but I can ack it  :)
Apr 09 00:03:11 <stintel> rsalvaterra: thanks, acked
Apr 09 00:03:58 <stintel> I should probably hit the sack too. not working tomorrow but weather is improving so summer wheels
Apr 09 00:07:41 <rsalvaterra> stintel: Oh, I remembered…
Apr 09 00:07:59 <rsalvaterra> We probably should backport this to 21.x, right?
Apr 09 00:08:08 <stintel> I think it makes sense
Apr 09 00:08:11 <rsalvaterra> The patch I sent is against master.
Apr 09 00:09:04 <rsalvaterra> (But it should apply to 21.x.)
Apr 09 00:09:44 <mangix> rsalvaterra: in what way is 5.4 going the way of the dodo?
Apr 09 00:10:46 <rsalvaterra> mangix: In the master's way… :P
Apr 09 00:10:58 <rsalvaterra> … hopefully…
Apr 09 00:11:14 <mangix> right. but not in kernel.org terms
Apr 09 00:11:35 <mangix> 4.4 will apparently be supported until 2037...
Apr 09 00:11:53 <stintel> o_O
Apr 09 00:11:58 <rsalvaterra> 2037?! Jesus…!
Apr 09 00:12:17 <mangix> yeah. japan wants super long LTS
Apr 09 00:12:32 <mangix> for their street lights and whatnot
Apr 09 00:13:31 <mangix> speaking of japan, I should probably email the NILFS2 maintainer...
Apr 09 00:14:00 <rsalvaterra> Wait… they are *updating* their kernels in the street lighting system? Shouldn't that be a completely hermetic system? o_O
Apr 09 00:14:13 <mangix> beats me
Apr 09 00:15:50 <mangix> reference: https://youtu.be/vyenmLqJQjs?t=685
Apr 09 00:18:28 <rsalvaterra> mangix: Gregkh's presentations are always brilliant. :)
Apr 09 00:19:25 <mangix> funny, he said he'll probably have a stop light on his desk eventually
Apr 09 00:20:32 <mangix> it always amazes me just how many changes get backported
Apr 09 00:20:41 <rsalvaterra> mangix: Wouldn't shock me. Have you seen his box of USB devices? :P
Apr 09 00:20:50 <mangix> i have not
Apr 09 00:23:08 <mangix> I wonder if ksmbd should be moved to base
Apr 09 00:23:22 <Mister_X> I have an old style traffic light with incandescent light bulbs, and thought about using it in my garage to let me know when it's good enough to close it
Apr 09 00:23:23 <mangix> doing updates in the packages feed is a nightmare
Apr 09 00:24:02 <Mister_X> there is a company that does boards to automatically switch between the different colors, but that's the boring thing to do
Apr 09 00:24:46 <stintel> hurricos: is the TODO in https://forum.openwrt.org/t/wip-porting-openwrt-to-cavium-cn6640-snic10e-octeon-ii-nic/88461 up-to-date?
Apr 09 00:33:20 <stintel> hurricos: I've got two of those cards. I didn't find 1GiB NAND, but didn't look very hard either. found the 64Mb NOR, and a 256Kb and a 512Kb I2C serial flash (never even heard of those)
Apr 09 00:34:47 <stintel> hurricos: right now I'm waiting for some DAC cables so I can mess around with tftp from u-boot. I can probably help with sysupgrade
Apr 09 01:04:40 <Grommish> mangix: Aww, updates to packages, just call update ;p >_<
Apr 09 01:04:57 <Grommish> mangix: Seriously though, can you think of another way of going that suricata-update package without being janky
Apr 09 01:06:37 <Grommish> ^- I mean, not AS janky
Apr 09 01:09:27 <mangix> what?
Apr 09 01:10:27 <Grommish> that update package. it's jank.. but I can't think of another way to do it
Apr 09 01:10:35 <Grommish> the package as a whole, not the pip3 part
Apr 09 02:26:13 <OutBackDingo> seems openwrt trunk is having issues with modemmanager https://pastebin.com/HEhZWZ61
**** ENDING LOGGING AT Fri Apr 09 03:00:09 2021