On 2019-01-28 12:16, Stanislaw Gruszka wrote: > On Mon, Jan 28, 2019 at 10:02:01AM +0100, Stanislaw Gruszka wrote: >> On Mon, Jan 28, 2019 at 09:41:45AM +0100, Felix Fietkau wrote: >> > >> Moreover I am a little worried about tpt regressions with this patch. >> > >> Are you sure that if you use complete different mac addresses on a multivif scenario >> > >> you can get the same tpt on all the interfaces? Could you please provide some >> > >> tpt results? >> > > >> > > How exactly posted patch can cause tpt regression ? >> > > >> > > Posted patch just add possibility to configure HW MAC address >> > > by this: >> > > >> > > iw dev wlan0 del >> > > iw phy phy0 interface add wlan0 type managed addr 00:11:22:33:44:55 >> > > >> > > what is feature of mt76x2u. Patch just extend that possibly to other >> > > mt76x02 devices and allow to remove custom mt76x2u add_interfacea >> > > callback. >> > The main part that could cause issues is that you're changing the way >> > that the vif index is calculated. Without the patch, it's calculated >> > from the MAC address in a way consistent with what the hardware expects. >> > With the patch, it's just allocated from a mask. >> > The vif index ends up being passed down to the hardware as a BSS index >> > WCID attribute in mt76x02_mac_wcid_setup. >> > We would have to run some tests with multiple AP interfaces, bringing up >> > secondary interfaces in a different order to see if there are any >> > regressions there if the BSS index no longer matches the MAC address >> > based index. >> >> Ok, that objection make sense. I'll check that. > > I'm not sure if I'm doing something wrong or current code is > wrong. But when I configure multi bssid's is hostapd.conf like this: > > 02:aa:bb:cc:dd:e0 > 06:aa:bb:cc:dd:e0 > 0a:aa:bb:cc:dd:e0 > > hostapd fail with "Too many bits in the BSSID mask" error . To make hostapd > work, I have configure bssid's like this: Do you have a bssid mask set? I don't think the current code does that. Also, in OpenWrt, I didn't see any issue like that. > 02:aa:bb:cc:dd:e0 > 02:aa:bb:cc:dd:e4 > 02:aa:bb:cc:dd:e8 > > But this ends up with the same index in mt76 for diffrent vif's. Seems like > calculating of the index should be fixed by: > > if (vif->addr[0] & BIT(1)) > idx = 1 + (((dev->mt76.macaddr[5] ^ vif->addr[5]) >> 2) & 7); This MAC adddress allocation scheme will cause problems if you have multiple devices next to each other that have consecutive MAC addresses. While it may sound unlikely, I do know people that encountered this issue (though with QCA based hardware), and it took us quite a while to figure out what was messing up their network ;) - Felix
