FT status and macvlan performance problems

[Matteo Croce]

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
>



-- 
Matteo Croce
Ubuntu - Linux For Human Beings

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