FT status and macvlan performance problems

michael-dev at fami-braun.de michael-dev at fami-braun.de
Sat Mar 25 03:06:30 PDT 2017


one hostapd process can easily cover multiple phy. Just start it with multiple config files for example.

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

More information about the Hostap mailing list