FT status and macvlan performance problems

Matteo Croce matteo.croce at canonical.com
Sat Mar 25 03:39:04 PDT 2017

Well, that's true, seems to work.
I don't know why all the firmwares I know start an instance per phy,
is it a new feature or just undocumented?


2017-03-25 11:06 GMT+01:00  <michael-dev at fami-braun.de>:
> Hi,
> one hostapd process can easily cover multiple phy. Just start it with multiple config files for example.
> Regards,
> Michael Braun
> Am 24. März 2017 23:24:39 MEZ schrieb Matteo Croce <matteo.croce at canonical.com>:
>>Right, an hostapd instance can handle multiple SSIDs for the same
>>but with multiple radios you nees to start an instance per physical
>>2017-03-24 23:12 GMT+01:00 Simon Wunderlich
>><simon.wunderlich at openmesh.com>:
>>> 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
>>>> > 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)
>>>> > Access
>>>> > points, enabling macvlans on top of bridges result in an
>>>> > 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 /
>>>> 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
>>>> traffic, so that performance problem did not affect me.
>>>> Aspects to consider:
>>>>   - having a macvlan device enables adding a local mac address also
>>>> non-bridge lower devices, e.g. ethX or vpntapX.
>>>>   - Benjamin's patch does not address the need for marking a mac
>>>> 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
>>>> covered as well
>>>> I'm think about the following solutions
>>>> i) enhance kernel macvlan driver so that it can avoid using
>>>> mode if lowerdev is a bridge by marking its mac address as local to
>>>> bridge
>>>> ii) tweak bridge fdb instead of using macvlan thus requiring
>>>> (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
>>>> 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
>>> access point (2.4 and 5 GHz). Creating two hostapd processes in this
>>case is
>>> the standard procedure in OpenWRT.
>>> Cheers,
>>>      Simon
>>> _______________________________________________
>>> Hostap mailing list
>>> Hostap at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/hostap

Matteo Croce
Ubuntu - Linux For Human Beings

perl -e 'for($t=0;;$t++){print chr($t*($t>>8|$t>>13)&255)}' |aplay

More information about the Hostap mailing list