FT status and macvlan performance problems

[michael-dev]

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