Re: FT status and macvlan performance problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Am 24.03.2017 15:25, schrieb Simon Wunderlich:
sorry for the late follow-up, I'd like to discuss and issue regarding your FT patches sent by you. We have tested both Benjamin and your patches, and found some performance problems. With our QCA9558/988x (using ath10k) based Access points, enabling macvlans on top of bridges result in an performance drop of
30-40%.

the reasons for adding macvlan devices were:

a) the bssid is not local to the bridge / ft_iface already
b) there are two hostapd instances running on the same bridge / ft_iface device
c) the lowerdev / ft_iface might not be a bridge

The macvlan device is only used for low rate AP-AP-control traffic.

Im my use case, the related lower device is only used for AP-AP-control traffic, so that performance problem did not affect me.

Aspects to consider:
- having a macvlan device enables adding a local mac address also to non-bridge lower devices, e.g. ethX or vpntapX. - Benjamin's patch does not address the need for marking a mac address as local to the bridge - With Benjamin's patch [1], the local delivery within hostapd might no longer be required as traffic between different hapd instances might be covered as well

I'm think about the following solutions
i) enhance kernel macvlan driver so that it can avoid using promisicous mode if lowerdev is a bridge by marking its mac address as local to the bridge ii) tweak bridge fdb instead of using macvlan thus requiring lowerdev (ft_iface) to be a bridge iii) use benjamin's patch [1] anyway and maybe avoid the need for hostapd internal delivery

Obviously, i) would benefit all other maclvan-on-top-of-bridge users as well.

Still, I'm wondering why one would need multiple hostapd processes running on an AP?

So far, I have not seen your patch [2] merged and it's marked deferred in patchwork [3]. Are you still working on the patch? Or is it in some queue which I didn't find, or superseded somehow? Would you consider reworking it to
be usable without macvlans?

I'm working on a modification of the FT AP-AP control protocol and that should be completed first. It is in my queue: https://github.com/michael-dev/hostapd/commits/dev-20170323

Regards,
M. Braun

[1] https://www.spinics.net/lists/hostap/msg02219.html

_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux