FT status and macvlan performance problems

Simon Wunderlich simon.wunderlich at openmesh.com
Fri Mar 24 15:12:20 PDT 2017

On Friday, March 24, 2017 10:51:27 PM CET michael-dev wrote:
> 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?

Thank you for your answer!

At least this last question is easy to answer on a Friday evening - we have 
one hostapd instance per phy, so its two instances running on a dual band 
access point (2.4 and 5 GHz). Creating two hostapd processes in this case is 
the standard procedure in OpenWRT.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20170324/a9b89590/attachment.sig>

More information about the Hostap mailing list