<shibboleth>
so, master is now missing the regular pre-defined tables, even with -legacy?
rua has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest315
srslypascal has joined #openwrt-devel
<shibboleth>
even more fun, if you preload iptables-nft it gives you warning that it detects legacy tables, but if you then also preload -legacy it can't see them?
pony has quit [Read error: Connection reset by peer]
pony has joined #openwrt-devel
valku has joined #openwrt-devel
aiyion has joined #openwrt-devel
pony has quit [Ping timeout: 480 seconds]
Monkeh has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
pony has joined #openwrt-devel
rua has joined #openwrt-devel
aiyion has quit [Remote host closed the connection]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
srslypascal is now known as Guest323
srslypascal has joined #openwrt-devel
Guest323 has quit [Ping timeout: 480 seconds]
floof58 has quit [Quit: floof58]
floof58 has joined #openwrt-devel
<arnd>
nbd, rmilecki: the bytewise access only happens on targets without unaligned access, such as ARMv5.
<nbd>
ah, okay
<arnd>
On armv7, the packed attribute prevents Multi-register stores (strd or stm).
<nbd>
there are some mips devices with bcma + bgmac, right?
<arnd>
I suppose stm would be ideal here, to write all four 32-bit words in the descriptor at once
<nbd>
so i guess for mips it makes sense to add __aligned(4)
<arnd>
Might be worth trying an inline asm with stm as an experiment, to see if that improves anythin
aiyion has joined #openwrt-devel
<nbd>
would gcc maybe generate stm if we use __aligned(16)?
<arnd>
Dropping the __packed is usually the best if possible
robimarko has quit [Quit: Leaving]
goliath has joined #openwrt-devel
<hauke>
rsalvaterra: you can merge the kernel 5.15 minor version update
<hauke>
nbd: yes there are some MIPS devices with bgmac
<hauke>
arm is only cortex a9 and cortex a53
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Borromini has joined #openwrt-devel
<xdarklight>
hauke: I investigated the "failed to add ... to fdb: -22" error with GSWIP on Linux 5.15. what do you think about https://paste.debian.net/1240458/ ? it seems like that error is linked to the port not being part of a bridge yet. my understanding is that managing the FDB should still work, regardless of the porting being part of a bridge (or not). not sure if my testing approach is correct but I configured a HH5A's Ethernet WAN port to
<xdarklight>
connect to my LAN -> "bridge fdb show" shows all learned MAC addresses for the Ethernet WAN interface
<arnd>
nbd: regarding the stm, the only way to force the compiler to produce that is an inline asm. If that helps, we can try to come up with a wrapper function provided by an arch header
<rsalvaterra>
hauke: Ok, will do, thanks!
<arnd>
I think it's possible to avoid a lot of the cache operations when using XDP. That has a larger potential for improving performance, but I have no idea how that works for the NAT use case
Borromini has quit [Ping timeout: 480 seconds]
<nbd>
arnd: unfortunately XDP is useless when it comes to handling forwarding between regular LAN and wifi devices
<nbd>
there isn't much need for it for NAT either
<nbd>
we already have a fast path that catches packets via an early ingress hook, does the required transformations and redirects them to the output device
<nbd>
(flow offload)
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<arnd>
nbd: but does flow offload let you skip the cache invalidation on the SKB data?
<hauke>
xdarklight: looks good
<nbd>
arnd: well, the embedded devices that we work with don't have any hw xdp support
<nbd>
and sw xdp doesn't let us skip the cache invalidation
<nbd>
a lot of platforms have hw support for offloading flows though
<nbd>
i think many broadcom platforms as well
<nbd>
though we don't support hw offload on those yet
<arnd>
ok, I see
<hauke>
xdarklight: does it configure your curent MAC address?
<xdarklight>
hauke: yes, it configures the port's MAC address on startup. "bridge fdb show" lists the port's own MAC address and also the MAC address of the other side of the connection
<nbd>
until recently i was very interested in using XDP for improving forwarding
<nbd>
then i made a bridge forwarding accelerator based on XDP
<nbd>
where i had to use generic XDP to make it work
<nbd>
but then i ran into issues with headroom and was told that nobody should use generic XDP for anything that matters :)
<arnd>
it looks like some of the drivers I saw don't actually use DMA_ATTR_SKIP_CPU_SYNC for XDP but instead use it as a different kind of optimization, see 966df6ded24d ("lan743x: sync only the received area of an rx ring buffer"). I think this approach should work with bgmac as well
<arnd>
saves a few cache operations when receiving buffers that are shorter than MTU. This probably makes a measurable difference on Cortex-A9's external L2 cache controller, but less so on other chips
<xdarklight>
hauke: hmm, I did some more debugging and I think my fix is not correct. DSA tries to do FDB access on the CPU port. is this somehow supported?
robimarko has joined #openwrt-devel
<rmilecki>
nbd: my priority is bcm53xx (arm) AKA Northstar and bcm4908 (arm64), bcm47xx is getting ancient
<rmilecki>
arnd: that minimal sync in lan743x looks interesting, I have to take a look at that
rua has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 480 seconds]
jmeno has quit [Remote host closed the connection]
pedropt has joined #openwrt-devel
<pedropt>
hi everyone
<pedropt>
can someone here give me an help on flashin dir 645 using SPI
goliath has quit [Quit: SIGSEGV]
<pedropt>
i flashed the full openwrt factory but wont start , i believe the bootload was not included in the bin from openwrt file , however i made a backup from the previous one witch i can reflash , my question is witch address in chip 25L6406E should i start to write openwrt image ?
<hauke>
xdarklight: It should also work on the CPU port
<hauke>
it is a normal port
<hauke>
it probably wants to configure the mac address of the device on the CPU port to make sure packets to the CPU get forwared to that port
<hauke>
this is a fixed forwarding rule, if the HW sees this mac address it will forward the packet to that port
<xdarklight>
hauke: ok, thanks. one more question: looking at the vendor driver *shrug* I found that they are setting the gswip_pce_table_entry.index field to the first available one (by reading all table entries and finding the first one where valid == false). but upstream we're not setting the index field for FDB add/delete - is this correct?
Luke-Jr has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
minimal has quit [Quit: Leaving]
rua has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
<hauke>
xdarklight: I think it will find a free entry
<xdarklight>
hauke: hmm, I don't think so. see gswip_pce_table_entry_read() where it takes tbl->key_mode to decide whether to use GSWIP_PCE_TBL_CTRL_OPMOD_KSRD (I assume this is "read entry based on the key") or GSWIP_PCE_TBL_CTRL_OPMOD_ADRD (which I assume is "read entry based on address"). the index field in struct gswip_pce_table_entry has: u16 index; // PCE_TBL_ADDR.ADDR = pData->table_index
<pedro_am>
i am unable to upgrade firmware for tplink ac1200 c6 3.20 , it says "Unable to upgrade"
<pedro_am>
any tips
<xdarklight>
hauke: ah, I missed that you're setting key_mode to true :-)
<xdarklight>
hauke: the vendor driver sets it to false, so I guess it's fine as-is. sorry for judging too quick
bluew has quit [Ping timeout: 480 seconds]
<pedro_am>
looks like the problem here was the extension of the file
bluew has joined #openwrt-devel
pedropt has joined #openwrt-devel
pedro_am has quit [Ping timeout: 480 seconds]
<xdarklight>
hauke: one more question: do you remember why you are using "port + 1" as FID of a single port bridge (instead of just using "port")?
<xdarklight>
hauke: does 0 have some special meaning? I'm asking because if I want to allow managing the CPU port's FDB then either I need to start counting at 0 or change all other loops to start counting at (max_ports + 1) (as CPU port = 6 + 1 = 7, which is the same as the start index for looking up a bridge in priv->vlans)
robimarko has quit [Quit: Leaving]
pedro_am has joined #openwrt-devel
pedropt has quit [Ping timeout: 480 seconds]
<hurricos>
some really odd network corruption / packet loss issues on realtek
pedropt has joined #openwrt-devel
<hurricos>
probably time for a sysupgrade to something bleeding-edge
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
pedro_am has quit [Ping timeout: 480 seconds]
pedro_am has joined #openwrt-devel
pedropt has quit [Ping timeout: 480 seconds]
pedropt has joined #openwrt-devel
pedro_am has quit [Ping timeout: 480 seconds]
pedro_am has joined #openwrt-devel
pedropt has quit [Ping timeout: 480 seconds]
pedropt has joined #openwrt-devel
pedropt has quit [Remote host closed the connection]
<xdarklight>
hauke: that's what I have for today: https://github.com/xdarklight/linux/commits/lantiq-gswip-fixes-20220510 - it seems that all FDB operations are happening on the CPU port directly, nothing's happening for the other ports. if you have any idea how to properly test this then please let me know. otherwise I'll send an email to the netdev/DSA maintainers in the next days, asking for their help
<rsalvaterra>
Per-patcket power control…? This feels a lot like Minstrel Blues…!
<rsalvaterra>
*packet
<hauke>
xdarklight: I wil try to look at this on Wednessday
<hauke>
I avoided the fid 0 becasue this is the default fid
<hauke>
I do not know if it was specail, but something old could still use it
<hauke>
but I never ran into a specific problem
<hauke>
as long as port isolation is not activated the switch will bridge between all ports with the same fid
<hauke>
when a packet is received on a port the switch checks the GSWIP_TABLE_VLAN_MAPPING table I think to get the VLAN handling and then it also gets the vid
<hauke>
then it looks into the GSWIP_TABLE_MAC_BRIDGE based on the fid and the mac and checks where to forward the packet to
<hauke>
the GSWIP_TABLE_MAC_BRIDGE table is also filled automatically with the source mac address
<hauke>
xdarklight: for testing you should make sure that the switch does not forweard packet even braodcast between the port whjen they are not in a bridge