ptudor has quit [Ping timeout: 480 seconds]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
dmtsza has joined #openwrt-devel
dmtsza has left #openwrt-devel [#openwrt-devel]
dmtsza has joined #openwrt-devel
dmtsza has quit [Quit: dmtsza]
philipp64 has quit [Quit: philipp64]
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 99.8% packages reproducible in our current test framework.)
danitool has quit [Ping timeout: 480 seconds]
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
Danct12 has quit [Ping timeout: 480 seconds]
iocampomx has quit [Read error: No route to host]
iocampomx has joined #openwrt-devel
Danct12 has joined #openwrt-devel
rmilecki has quit [Read error: Connection reset by peer]
rmilecki has joined #openwrt-devel
Borromini has joined #openwrt-devel
ptudor has joined #openwrt-devel
iocampomx has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
Misanthropos has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
robimarko has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
goliath has joined #openwrt-devel
rua has quit [Quit: Leaving.]
Kevinjil has joined #openwrt-devel
rua has joined #openwrt-devel
<Kevinjil> Hey, about a month ago I submitted my first PR to the OpenWRT github repo. I was wondering what the next steps to take are to get it approved/merged. Could someone perhaps give me some directions? :)
tidalf has quit [Ping timeout: 480 seconds]
tidalf has joined #openwrt-devel
dmtsza has joined #openwrt-devel
dmtsza has quit []
owrt-images-builds has joined #openwrt-devel
castiel652 has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
zer0def has quit [Quit: zer0def]
zer0def has joined #openwrt-devel
Tapper has joined #openwrt-devel
<Tapper> I see the new stuff for ipq86 the switch to dsa. If I flash a new build to my r7800 do I have to redo my configs?
<jakllsch> basically, yes. if it's been done right it won't even let you sysupgrade
<robimarko> Kevinjil: What is the PR?
<robimarko> It needs to get reviewed
castiel652 has quit [Quit: Leaving]
<Kevinjil> @robimarko: It's a new device support: https://github.com/openwrt/openwrt/pull/13396
swalker has quit [Remote host closed the connection]
swalker has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
bluew has joined #openwrt-devel
torv has quit [Quit: torv]
torv has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #openwrt-devel
<linusw> Does anyone have a datasheet for the Marvell MV88E6085 DSA switch?
<robimarko> Kevinjil: Yeah, Realtek target explains it
<robimarko> It would be great to get reviews from non-mainters at least
tidalf has quit [Ping timeout: 480 seconds]
<Kevinjil> Hmm, is the realtek target having few maintainers?
<robimarko> linusw: I have access to the datasheet, what info do you need?
<linusw> robimarko: how to set the MTU
<linusw> the mv88e6085_ops in mv88e6xxx is missing set_max_frame_size()...
<robimarko> linusw: I think its because 6085 only allows selecting between 1522/1518 or 1632 max frame size
<linusw> robimarko: I can work with that, right now it can't select anything.
<linusw> robimarko: ohhhhh....
<linusw> sneaky that it's hidden at the bottom there
<robimarko> I can confirm that its toggling the correct bit 10
<linusw> OK then I check why the system is complaining, this is present in v6.1 I presume.
<robimarko> Yes, the OP is in 6.1 as well
<robimarko> What error are you seeing?
<robimarko> linusw: Well, that is not the 6085 switch
<linusw> robimarko: yeah I was fooled by the dev_err() macro as usual
<robimarko> Is there a full log with the switch model?
<robimarko> 6085 compatible is used in the driver to get the base register basically so it can read the ID
<robimarko> Oh, its 6352
<robimarko> Which does not have the max frame size OP
<linusw> Aha so that's the thingie that we need to fix
<robimarko> linusw: I think it doesnt support MTU size change
<robimarko> But that is present in 6.1 as well
<robimarko> Oh, but it has port_set_jumbo_size OP
<robimarko> So, that commit doesnt apply
<linusw> hm hm
<linusw> is that op picky about the size or something, so it needs to be exactly the supported size and it doesn't "roof" the MTU?
<linusw> but that looks just fine... hm
Borromini has joined #openwrt-devel
<robimarko> Yes, but something is weird as -34 is -ERANGE
<robimarko> I would start by printing the requested size
<linusw> Hm hm I'll dig into it.
<linusw> That sounds like an error returned by mv88e6xxx_port_write() or something.
<robimarko> You are probably going to need to chase the source of the error code
<linusw> Yup
<linusw> thanks a lot Robert!
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
dmtsza has joined #openwrt-devel
<swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
dmtsza has quit [Quit: dmtsza]
Danct12 has quit [Quit: CAROUSEL - BROUGHT TO YOU BY AVIVA AND NEONI]
Danct12 has joined #openwrt-devel
Danct12 has quit []
Danct12 has joined #openwrt-devel
<lynxis> swalker: thanks!
Borromini has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
goliath has joined #openwrt-devel
<linusw> robimarko: I drilled into it and it turns out to be that the outoftree driver target/linux/bmips/files/drivers/net/ethernet/broadcom/bcm6368-enetsw.c reports a max MTU of 1510.
<linusw> and the DSA code want to set it to 1514 for the DSA hierarchy we have DSA switch to DSA switch.
<linusw> And clearly it supports a bit more than its own overhead but I think this 6368/6318/6328 ethernet switch is another of these things we do not have a datasheet for...
<linusw> Its like a DSA without any ethernet master behind it, pretty cool actually.
<linusw> KanjiMonster is in the file as author but don't know if that's mostly copied code.
<Habbie> just for my curiosity, what does it mean for a DSA to not have an ethernet master?
<linusw> Habbie: instead of eg eth0 -> switch through a fixed link, the switch is directly on the SoC, with no fixed internal link or anything.
<linusw> You send out frames through the switch, it is an ethernet driver.
<Habbie> ah
<Habbie> so how does 'linux' talk to the world in such a setup?
<Habbie> ah
<Habbie> so you're not a fake port on it
<KanjiMonster> usually the cpu port where you send the frames to is a port for most intents and purposes
<Habbie> right
<linusw> I can understand why this ethernet-switch has not been upstreamed. I can imagine the discussions that would ensue.
<linusw> is Alvaro on this IRC channel?
<linusw> noltari: OK there you are :)
<KanjiMonster> linusw: I don't remember exactly what the maximum MTU is; the core limitation is the dma channel thingy, which is IIRC limited to 2k descriptors, but in theory you could chain multiple
Kevinjil has quit [Remote host closed the connection]
<linusw> KanjiMonster: that sounds like the MTU is actually ETH_MAX_MTU
<KanjiMonster> the switch itself supports jumboframes though (up to 9728 bytes)
<linusw> KanjiMonster: sounds like we should bump it up to that then? priv->rx_buf_size = ALIGN(ndev->mtu + ENETSW_MTU_OVERHEAD, ENETSW_DMA_MAXBURST * 4); here ndev->mtu should then be 9728-ENETSW_MTU_OVERHEAD I think.
<KanjiMonster> linusw: the dma code isn't ready for handling oversized frames
<linusw> aha
<KanjiMonster> documentation which I may or may not have says default maximum frame size is 1536, everything larger will be dropped by the switch itself (when jumbo is disabled)
<linusw> That headroom works for me. I will author some rogue patch for this then.
<KanjiMonster> "NOTE: Engineering only. Do not release this reg to customers" lol
<linusw> Haha I love it.
<Habbie> i have found many PDFs with such notes
<Habbie> also "for huawei use only" ok thanks!
<KanjiMonster> unfortunately the public MDK does not have registers for the 6368 integrated switch (or the 5388 it seems to be based on)
<KanjiMonster> "NOTE: this bit is added per YiHsien's request, just in case we need to set it back to old mode when any thing goes wrong, which shouldn't happen." also fun
robimarko has quit [Remote host closed the connection]
<linusw> KanjiMonster, noltari: I sent a patch, dunno if I should rather make pull requests on github these days? I'm a bit oldschool.
<KanjiMonster> either one is fine
<KanjiMonster> linusw: you are confusing mtu and maximum frame length ;)
<dwfreed> mtu is layer 3 length
<linusw> right you did say 1536 is maximul frame size mea culpa
<linusw> so MTU should be something like 1536-ENETSW_MTU_OVERHEAD = 1536-(18+4+6) = 1508
<Habbie> where do 18, 4, and 6 come from?
<KanjiMonster> ethernet header length (+FCS), vlan tag length, broadcom header length
<Habbie> vlan: right! broadcom: i believe you
<linusw> and now it is set to 1506 so at least two bytes more.
<Habbie> and, found my confusion, fcs is 4, not 2 :)
<KanjiMonster> though I'm somewhat sure the broadcom header does not count for the 1536 bytes, since the header is only added by the switch when sending packets to the cpu port, and stripped by it when receiving packets on the cpu port
<linusw> KanjiMonster: 1536-(18+4) = 1514 sounds like exactly what I need, and what is used with the Marvell switch so I will go with that.
<linusw> I'll fix the patch.
<KanjiMonster> also please make sure that these sizes do actually work
<KanjiMonster> (set mtu to max, try to ping with df)
<linusw> OK
<linusw> I'll include the test in the changelog
digitalcircuit has joined #openwrt-devel
<KanjiMonster> Habbie: the (legacy) broadcom header length of 6 causes the ip header to be non aligned to 4 bytes - but legacy bcm63xx enet also had the issue that dma needed 4 byte alignment, causing the ip header also be non-aligned
<Habbie> oh fun
<KanjiMonster> so combined they make the ip header aligned again
<Habbie> heh
<dwfreed> KanjiMonster: a 6 byte extra header *would* cause the IP header to start on a 4 byte alignment
<dwfreed> 6 (dest mac) + 6 (src mac) + 2 (ethertype) = 14
<KanjiMonster> dwfreed: usually ethernet drivers use 2-byte alignment for dma, so the ip header becomes 4 byte aligned. if you then insert a 6 byte header, it breaks the alignment
<dwfreed> eh? that doesn't make any sense
<KanjiMonster> I mean you write the packet at offset x2, so the ip header then will be at 2 + 18 = 20 => 4 byte aligned
<KanjiMonster> (or *6 or *a or *e ;p)
<dwfreed> 2 byte offset, not 2 byte alignment
<linusw> I do this from my host ping -s 1472 -M do 192.168.1.220
<linusw> PING 192.168.1.220 (192.168.1.220) 1472(1500) bytes of data.
<linusw> 1480 bytes from 192.168.1.220: icmp_seq=1 ttl=64 time=0.638 ms (etc)
<dwfreed> the 1480 byte response includes the icmp header, iirc
<KanjiMonster> linusw: try increasing the mtu to max what is allowed on both sides, and then try to ping with max size
<KanjiMonster> so assuming you ping through the dsa switch setting a mtu of ... 1506?
<linusw> KanjiMonster: the max MTU on the host is 9194 so bumped it to that
<linusw> ping -s 1472 192.168.1.2 resulting in 1500 on the wire is actually the biggest that works.
<KanjiMonster> just to make sure, you also increase the mtu on the router side?
<linusw> The Marvell switch adds 8 bytes DSA tag, then the enetsw adds 6 bytes DSA tag = 1514
<linusw> KanjiMonster: yes it is bumped by default to 1514 by the driver
<KanjiMonster> you probably need to bump it to 1520 then
<KanjiMonster> not sure if you can also instead bump the mtu on the lan* port you use
<linusw> Hm if you mean eth0 (enetsw) I just patched it to do max 1514 MTU
<linusw> 1536-(18+4)
<KanjiMonster> I'm somewhat sure that the broadcom header doesn't count for the switch, so the actual max mtu is 1536 - (18+4) without the broadcom header, and 1536 - (18+4) + 6 with
<linusw> oh hm I can bump the MTU of the br-lan or br-wan bridges
<KanjiMonster> yeah, but that doesn't change the mtu of the bridge members
<linusw> no right
<linusw> bridge members don't like to go above 1500 with the Marvell thing.
<KanjiMonster> so did you increase the max_mtu for enetsw to 1520? because if it's still 1514, then linux may say that it can't do more as you are already at max
<linusw> KanjiMonster: Ah I didn't do that because I expected the 6 bytes DSA tag not to be included, but I'll try with that and see what happens.
<linusw> OK did that by hardcoding 1520 and bumping the interface to an MTU of 1506 which works now
<linusw> the switch does not feel good at all if I do that, haha.
<linusw> not even DHCP behaves well anymore.
<KanjiMonster> I'll be heading to bed now. If you feel daring, you could try to check if a value between 1500 and 1506 still works fine
<linusw> I need to sleep too, I'll experiment some! Thanks!
goliath has quit [Quit: SIGSEGV]
Tapper has quit [Ping timeout: 480 seconds]
mcbridematt has quit [Quit: Leaving]
<owrt-images-builds> Build [#126](https://buildbot.staging.openwrt.org/images/#/builders/71/builds/126) of `master_sunxi/cortexa7` completed successfully.