Re: [B.A.T.M.A.N.] [PATCH maint] batman-adv: Fix TT sync flags for intermediate TT responses

On 09/05/18 03:20, Marek Lindner wrote: > On Sunday, May 6, 2018 4:23:37 AM HKT Sven Eckelmann wrote: >>> * batadv_tt_tvlv_generate() - fill the tvlv buff with the tt entries from >>> the * specified tt hash >>> * @bat_priv: the bat priv with all the soft interface information >>> @@ -2934,6 +29

Re: [B.A.T.M.A.N.] [PATCH maint] batman-adv: Fix TT sync flags for intermediate TT responses

On Sunday, May 6, 2018 4:23:37 AM HKT Sven Eckelmann wrote: > > * batadv_tt_tvlv_generate() - fill the tvlv buff with the tt entries from > > the * specified tt hash > > * @bat_priv: the bat priv with all the soft interface information > > @@ -2934,6 +2969,7 @@ static void batadv_tt_tvlv_generate(

Re: [B.A.T.M.A.N.] [PATCH v3 0/2] batman-adv: DHCP snooping for DAT

Name of failed tests ecsv/pu --- * kerneldoc ./net/batman-adv/distributed-arp-table.c Output of different failed tests ecsv/pu: kerneldoc ./net/batman-adv/distributed-arp-table.c

Re: [B.A.T.M.A.N.] [RFC 0/6] B.A.T.M.A.N. V - fallback to tp meter estimation if throughput otherwise not available

Name of failed tests ecsv/pu --- * checkpatch ./net/batman-adv/bat_v_elp.c * checkpatch ./net/batman-adv/tp_meter.c * checkpatch ./net/batman-adv/types.h * headers * kerneldoc ./net/batman-adv/routing.c * kerneldoc ./net/batman-adv/tp_meter.c * kerneldoc ./net/batm

[B.A.T.M.A.N.] [RFC 3/6] batman-adv: tp_meter - allow up to 10 queued sessions

Signed-off-by: Marek Lindner --- net/batman-adv/main.h | 6 -- net/batman-adv/tp_meter.c | 5 +++-- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h index 8da3c933..89dfaf87 100644 --- a/net/batman-adv/main.h +++ b/net/batman-adv

[B.A.T.M.A.N.] [RFC 5/6] batman-adv: to_meter - add option to perform one-hop test

From: Antonio Quartulli A link test is a TP session ran over a specific one-hop link, rather than towards an originator in the mesh. Signed-off-by: Antonio Quartulli --- include/uapi/linux/batadv_packet.h | 1 + net/batman-adv/netlink.c | 3 +- net/batman-adv/routing.c

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

Signed-off-by: Marek Lindner --- net/batman-adv/bat_v_elp.c | 62 -- net/batman-adv/bat_v_elp.h | 19 net/batman-adv/main.h | 1 + net/batman-adv/tp_meter.c | 25 +-- net/batman-adv/types.h | 9 ++ 5 files changed, 111 i

[B.A.T.M.A.N.] [RFC 2/6] batman-adv: tp_meter - don't check for existing session

From: Antonio Quartulli Since the conversion from kthread to queue worker it is not possible to run more than one "sender" session at a time. For this reason, checking if another session to the same destination is already scheduled is not useful anymore. Remove such check and allow the user to e

[B.A.T.M.A.N.] [RFC 1/6] batman-adv: tp_meter - prevent concurrent tp_meter sessions by using workqueue

From: Antonio Quartulli To ensure that no more than one tp_meter session runs at the same time, use an ordered workqueue instead of spawning one kthread per session. Signed-off-by: Antonio Quartulli --- net/batman-adv/main.c | 10 -- net/batman-adv/tp_meter.c | 73 ++---

[B.A.T.M.A.N.] [RFC 0/6] B.A.T.M.A.N. V - fallback to tp meter estimation if throughput otherwise not available

Under normal circumstances B.A.T.M.A.N. V retrieves the neighbor throughput values to populate its metric tables from the various drivers such as WiFi throughput tables and Ethernet throughput.. Whenever the interface drivers do not export link throughput information manual overrides become necess

[B.A.T.M.A.N.] [RFC 4/6] batman-adv: tp_meter - add caller distinction

The throughput meter can be called from user space as well as from the batman-adv kernel module itself. Add infrastructure to handle the different callers. Signed-off-by: Marek Lindner --- net/batman-adv/netlink.c | 2 +- net/batman-adv/tp_meter.c | 102 +-

Re: [B.A.T.M.A.N.] [RFC PATCH] batman-adv: mitigate issue when empty vlan is received

n Montag, 7. Mai 2018 12:23:57 CEST Sven Eckelmann wrote: > This would sound to me like the vlan should just be > created instead of adding this workaround. But maybe you should discuss the > details here with Antonio because at the end it is just about the different > ways of handling "!vlan" c