FT status and macvlan performance problems

[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
>radio,
>but with multiple radios you nees to start an instance per physical
>device.
>
>Cheers,
>
>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
>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.
>>
>> Cheers,
>>      Simon
>> _______________________________________________
>> Hostap mailing list
>> Hostap at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/hostap
>>