[BPI-R4] LRO/RSS etc upstreamed?

Hi @frank-w is LRO/RSS etc upstreamed do you know ? and on which kernel version?

thank you

Not yet,but recently i’ve send a RFC to netdev Mailinglist

https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/

But no comments yet. I have added these patches to my 6.18-rc branch so it will be included in my 6.18-main and my upcoming LTS branch.

2 Likes

Thank you for your post, raised speed from 4.5 gbit\s to 8.4 with this RSS option that you described

LRO is not started but anyway it sound much better

If someone is interested, here is a link to a Linux kernel patch set taken from a recent mtk-openwrt-feeds branch and adjusted for recent Linux branch: linux_6.19-pre-rc1_37bb2e72__mtk-openwrt-feeds_eb48282b_patches_+rss+lro+nft_flow_offload+64bit~almost_stock_mt7996.tar.xz
If I’ll have more time in the future, then maybe I’ll fork the Linux kernel git archive somewhere in public available repository with the patches applied.

- I keep the quilt format since it us used by mtk-openwrt-feeds, thus makes it easier to keep on track as well as cherry pick what is really needed.
- What is applied can be checked by opening the patches/series file which also has some comments; for now most of MediaTek provided mac80211 and mt76 patches are not applied, since even if they were modified to apply, they bring certain problems (e.g. recently since Linux kernel > 6.16 I’ve noticed that WiFi stops receiving traffic just after some time and/or amount of traffic served; I have a nearly full set of MediaTek patches applied to the Linux kernel v6.16-rc1 and working if someone is interested).
- What is tested is given after “+” signs in the archive name.
- MLO is not tested as I do not own a station type of device that is compatible with it.
- It uses @frank-w build scripts, yet I provide a trimmed kernel config file that should be just copied to the build directory.

How to apply and build:

cd <path_to_linux_kernel>
git checkout <linux_commit_from_patch_archive_file>
tar -xJf <path_to_patch_archive_file>
quilt push -a
sed -ri 's/^(board=bpi-.*)/#\1/' build.conf
sed -ri 's/^#(board=bpi-r4)/\1/' build.conf
bash build.sh importconfig
cp patches/config ../build/.config
bash build.sh build
bash build.sh pack

Which kernel do you use as base? I got message about requesting for access,please check rights on your gdrive.

I try to send a v3 today. Noticed that the part i dropped in v2 is needed for mt7986 rss and i try to get lro on mt7986 working (current patch seems to break lro on mt7988)

Sorry for the permissions, should be fixed by now.

I use today’s Linux 6.19 (pre-rc1) commit 37bb2e72, I try to keep precise info in the header of patches/series file.

BTW I had to revert your patch about sram (04c7aacc) since it was committed, it was causing all the time:

mt7530-mmio 15020000.switch: Failed to register DSA switch: -517

here is the boot log for reference: debian_6.18-rc1master_1760779590.log (54.0 KB)

Using a base in tovalds master in merge window is no good idea for this,either use rc1 or the last stable.

04c7aacc is no commit in my repo (not found by github,so i’m not sure why this is caused. But when you talk about sram you have to use dts and driver code from mainline and not simply overwrite with sdk files. The sram handling is different in mainline (dedicated sram node) and sdk (uses second reg property in eth node).

Currently i have some issues with mt7622 and non rss/lro related patches. 1 is after 6.18 (mmc probe order) and one is needed for mt7988,but breaks mt7622 network.