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