FT status and macvlan performance problems

[Matteo Croce]

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?

Cheers,

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
>>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