<dhewg>
that works well in general, this is just that channel anaysis thingy
<robimarko>
I know, but it still nice to have
<Ansuel>
(dhewg don't hate me ahahahah)
<dhewg>
hehe don't worry ;) and done
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
mark22k has quit [Quit: Ping timeout (120 seconds)]
mark22k has joined #openwrt-devel
Danct12 has quit [Quit: WeeChat 4.0.4]
slh64 has joined #openwrt-devel
rua has joined #openwrt-devel
Danct12 has joined #openwrt-devel
<mrkiko>
Ansuel: so, qca8k isn't upstream, the rest (ipqess and ...) is?
<Ansuel>
qca8k is upstream
<Ansuel>
ipqess is in progress (not by me) and ipq40xx driver no idea what will happen but also that... upstream in progress
<mrkiko>
Ansuel: thanks. Ok, I should understand at some point what driver does what :D that said, the device is running fine so far.
<robimarko>
IPQESS is getting converted to switchdev to satisfy the upstream wishes
<robimarko>
It will be using the common qca8k code
<robimarko>
Upstream thinks that the switch and ethernet controller are too tightly coupled for a traditional tag driver approach
minimal has joined #openwrt-devel
rua has quit [Quit: Leaving.]
<mrkiko>
robimarko: Ansuel: seems a good amount of work to do ... thanks for doing it
<robimarko>
Its not going to be me doing it, company I work for has hired devs to do it as its beyond my capability
<robimarko>
Nor I have time for that
<Ansuel>
robimarko so the idea of putting the port in the skb will be dropped?
<robimarko>
Ansuel, no idea currently but now they could do everything in the driver itself
<robimarko>
There isnt a need to carry the info to a tagger
<Ansuel>
watch ipq40xx having better perf than damn ipq806x -.-
<Ansuel>
(i mean it's already like that)
<robimarko>
Well, its only better on the account on more cores when you spread out the IRQ-s
f00b4r0 has quit [Read error: No route to host]
<Ansuel>
i think in general the ethernet design of ipq40xx is just better
f00b4r0 has joined #openwrt-devel
<robimarko>
Why?
<Ansuel>
more queue more interrupt... it's similar with what happen with ipq807x and ipq60xx...
<Ansuel>
as ipq807x, ipq806x I feel it's all designed with the use of nss cores...
<Ansuel>
while ipq40xx and ipq60xx is more designed to use the actual feature of the switch (more offload feature, more queue)
<robimarko>
Its designed to be exclusively used with NSS
<robimarko>
Otherwise its meh at best
<Ansuel>
in fact ipq806x idea was to send everything to nss and let nss handle the traffic so no reason to have multiple queue, just pass raw packet there with no handling
<Ansuel>
i'm honestly curious what will be the DSA perf with the new finding of the stmmac regression tho
<robimarko>
BTW, I am leaning more and more towards adding nss-drv for ipq807x and pushing traffic through it
<robimarko>
That should increase the performance even without any kind of offloading
<Ansuel>
yep for ipq807x that is the only way
<Ansuel>
for ipq60xx there may be a chance
<robimarko>
Nope
<robimarko>
IPQ60xx uses the same identical networking setup
<Ansuel>
isn't ipq60xx using v2?
<robimarko>
Nope
<robimarko>
Only the new WiFI 7 stuff uses that
<Ansuel>
.........
<robimarko>
PPPoE should benefit from having checksum offloading quite a bit
<robimarko>
It also exposes the API that in theory you can use to hoot into flow tables and offload stuff
<Ansuel>
main problem of nss-drv is that it waaay too big for what we need
<robimarko>
In terms of code to maintain or?
<Ansuel>
also symbol exported and size. we can ignore that but still... and patching the driver to disable all of them is a nightmare to maintain
rua has joined #openwrt-devel
<Ansuel>
for sure we can totally ignore the problem with packet getting dropped...
<robimarko>
I dont remember packets being dropped?
<robimarko>
The only issue I remember is that there is a lot of retries is GRO was used along with NSS
<Ansuel>
main problem was that when we started using nss-drv we had additional packet retry from iperf results
<robimarko>
Yeah, and that only happens with GRO
<robimarko>
Its a weird situation in which GRO increases perf but also retries
<robimarko>
So, QCA fixed it by never enabling GRO
<Ansuel>
aside from that nss-drv itself with our patches can be implemented right away
<robimarko>
Yeah, ever since you ported it to the standard DMA ops its not a nightmare and doesnt require any hacks
<Ansuel>
strange they still didn't include that patch... Would love to see my commit applied directly LOL
<robimarko>
It also allows using threaded NAPI on the dummy interface and increase the performance a bit more
<robimarko>
Ansuel: Wait till they try 6.1
<robimarko>
NSS-DRV is receiving minimal changes upstream, I think they are just maintaing it
<Ansuel>
it's strange tho i think nss-drv is a must for wifi offload
<Ansuel>
wifi7 is way too much heavy
<robimarko>
Well, its at point where they dont have anything new to add so they are just maintaining it
<robimarko>
All of the paths are there
<Ansuel>
well they offload even NTP packet LOL
<robimarko>
Cause that is too heavy to handle on the CPU
<robimarko>
:)
<robimarko>
BTW, I still havent figured out how to trigger my damn WLAN LED
<Ansuel>
where?
ptudor has joined #openwrt-devel
rua has quit [Quit: Leaving.]
filimonic has quit [Ping timeout: 480 seconds]
<robimarko>
In stupid QSDK
rua has joined #openwrt-devel
<nbd>
fyi, the new hostapd reload code is now in 23.05
goliath has quit [Quit: SIGSEGV]
castiel652 has joined #openwrt-devel
<castiel652>
hi room
xavifr has quit [Ping timeout: 480 seconds]
<lynxis>
hauke: about the commit 8b1cc1582ad / remove built-in vhost-net driver. I would like to have an image suitable to direct use as virtual machine image. should we add kmod-vhost as device package or should we have a new image for vms which contains all the different vm related drivers?
xback has quit [Remote host closed the connection]
sepf has joined #openwrt-devel
xback has joined #openwrt-devel
goliath has joined #openwrt-devel
xavifr has joined #openwrt-devel
Borromini has joined #openwrt-devel
castiel652 has quit [Quit: Leaving]
* philipp64
nbd: dumb question about shell scripting, but in jshn.sh (and other places) we have: export -- "$varname=\"$value\"" and in other places we have: eval "$varname=\"$value\"" instead. Why can't we just use the export all the time? Is it about not polluting the ENV space?
<philipp64>
Look at _json_set_var() (eval), __jshn_raw_append() (eval of an export), and _json_add_generic() (just an export)...
<philipp64>
In _json_set_var() we're typically using it to set a local variable, so I can understand if export on a local variable would interfere with scoping, etc.
<philipp64>
Hmm... tried to use the export method to set a local'd variable and it doesn't trounce the global of the same name...
<jeff___m>
Hi, can anyone help me understand why this patch hasn't been accepted? As far as I can tell people just stopped responding and it got left in limbo.
<karlp>
I don't believe that's been addressed at all, so I can understand why theres no big rush to move forward with it by anyone
<hauke>
lynxis: just add the kmod-vhost-net to the x86/64 target as default package
<hauke>
this target is not space constrained
<philipp64>
hauke: I wish we still had udev on x86_64. it makes sense to leave it off on devices that are SoC-based and everything is soldered on, but the x86_64 images aren't bound to a particular platform or board, so having more generic detection of what's populated makes more sense...
Borromini has quit [Quit: Lost terminal]
<philipp64>
I'm working with a board where the ethernet ports on one of the chips get ennumerated in the wrong order (relative to the labeling on the case), so udev would have been handy to be able to say "if we're running on this board, and the devpath is this, then assign the 4 ports #'s as (3-n) instead..."
<jeff___m>
karlp: I see the license issue with building boot firmware, but why can't Tim Harveys' patch go ahead that doesn't include the boot firmware to allows compiling from the main fork without the boot firmware license issue?
jeff___m has quit [Remote host closed the connection]
xback has quit [Remote host closed the connection]
xback has joined #openwrt-devel
<robimarko>
And you can boot without the boot FW?
philipp64 is now known as Guest526
philipp64 has joined #openwrt-devel
Guest526 has quit [Ping timeout: 480 seconds]
robimarko has quit [Remote host closed the connection]
sepf has quit [Ping timeout: 480 seconds]
jeff___m has joined #openwrt-devel
jeff___m has quit [Remote host closed the connection]
xavifr has quit [Ping timeout: 480 seconds]
sepf has joined #openwrt-devel
philipp64 has quit [Read error: Connection reset by peer]
philipp64 has joined #openwrt-devel
philipp64 has quit [Read error: Connection reset by peer]
philipp64 has joined #openwrt-devel
sepf has quit []
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #openwrt-devel
xback has quit [Remote host closed the connection]