Re: [B.A.T.M.A.N.] [PATCH v2 6/7] batman-adv: ELP - use tp meter to estimate the throughput if otherwise not available

Antonio Quartulli
2018-08-04T08:59:58Z

[-- Attachment #1.1: Type: text/plain, Size: 1181 bytes --]

Hi,

On 21/05/18 23:01, Linus Lüssing wrote:
> On Fri, May 18, 2018 at 09:47:53AM +0800, Marek Lindner wrote:
>> diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h
>> index 0a9bee88..148f23ad 100644
>> --- a/net/batman-adv/types.h
>> +++ b/net/batman-adv/types.h
>> @@ -583,6 +583,20 @@ struct batadv_hardif_neigh_node_bat_v {
>>
>> /** @metric_work: work queue callback item for metric update */
>> struct work_struct metric_work;
>> +
>> + /**
>> + * @tp_meter_running: tp meter measurements towards this neighbor in
>> + * progress
>> + */
>> + unsigned char tp_meter_running:1;
>
> I'm currently wondering: Would it make sense to prevent parallel
> tp meter execution not only to a specific neighbor but parallel
> executions on a hard-interface in general?
>

This flag prevents scheduling new measurements to this neighbour if one
has already been scheduled and has not returned any result yet.

What you are looking for is implemented in patch 1/7: a system-wide
queue prevents concurrent measurements at all. All the measurements are
serialized and performed one after the other.

Cheers,

--
Antonio Quartulli

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]