Hi,
I find your output slightly confusing. Maybe you can change your printk stuff
to something more like:
printk("%s %s:%u max_headroom %u\n", __FILE__, __func__, __LINE__, max_headroom);
On Thursday, 26 November 2020 00:14:35 CET Annika Wickert wrote:
> This is what I get from the bridge when bat0 is enslaved with the vxlan interface as member of batman ( https://elixir.bootlin.com/linux/latest/source/net/bridge/br_if.c#L311 )
> [ 36.959547] Bridge firewalling registered
> [ 522.221767] SKB Bridge br_if.c: max_headroom 0
> [ 522.221781] SKB Bridge br_if.c: new_hr 0
> [ 627.186129] SKB Bridge br_if.c: max_headroom 0
> [ 627.186139] SKB Bridge br_if.c: new_hr 0
> [ 627.616650] SKB Bridge br_if.c: new_hr 102
When is this shown? Does the batadv interface already have its hardif (slave)
interfaces attached at that point? And did the vxlan report the correct
needed_headroom to batadv before you've tried to attach the batadv interface
to the bridge?
Because the bridge can also only change its needed_headroom on interface add
or delete.
> Also BATMAN reports itself when initialized and seems not to propagate stuff up the stack on change?: (https://github.com/open-mesh-mirror/batman-adv/blob/master/net/batman-adv/hard-interface.c#L555 )
> [ 3350.212094] SKB hard-interface.h: soft_iface->needed_tailroom) 0
> [3350.212105] SKB hard-interface.h: soft_iface->needed_headroom) 358
> [ 3350.212116] SKB hard-interface.h: lower_headroom 70
> [ 3350.212126] SKB hard-interface.h: needed_headroom 102
Afaik, it is "propagating" its stuff by adjusting its own needed_headroom/
tailroom at this point. But there is no way to notify that the headroom/
tailroom was changed and the upper layers should recalculate it.
If you need something like this then we might to have a new
NETDEV_RESERVED_SPACE_CHANGE (or a better name OR maybe use a netdev_cmd with
a similar meaning). And then call this whenever the needed_headroom/
tailroom/... of an interface changes during its lifetime. And bridge/batman-
adv/ovs/... have to check the headroom in their notifier_call again when they
receive this event.
> Also added some debugging to Fragmentation.c in BATMAN after the patch:
> Nov 25 17:48:26 raspi-1gb.awlnx.space kernel: SKB Fragmentation.c: ll_reserved 96
> Nov 25 17:48:26 raspi-1gb.awlnx.space kernel: SKB Fragmentation.c: skb->len 762
> Nov 25 17:48:26 raspi-1gb.awlnx.space kernel: SKB Fragmentation.c: header_size 20
> Nov 25 17:48:26 raspi-1gb.awlnx.space kernel: SKB Fragmentation.c: fragment_size 762
> Nov 25 17:48:26 raspi-1gb.awlnx.space kernel: SKB Fragmentation.c: ll_reserved 96
>
> At the same time the VXLAN interface which is transported over Wireguard reports this (https://elixir.bootlin.com/linux/latest/source/drivers/net/vxlan.c#L2352 )
> [ 567.515778] SKB VXLAN vxlan.c: min_headroom 200
> [ 567.515792] SKB VXLAN vxlan.c: dst->header_len 0
> [ 567.515805] SKB VXLAN vxlan.c: VXLAN_HLEN 16
> [ 567.515819] SKB VXLAN vxlan.c: LL_RESERVED_SPACE(dst->dev) 144
> [ 567.515831] SKB VXLAN vxlan.c: iphdr_len 40
>
> So in my opinion the needed headroom reported by batman is wrong by maybe 200 ? As the min_headroom of vxlan seems to be 200 but BATMAN reports 102 up the stack to the bridge.
Could it be that the vxlan didn't had the correct needed_headroom when you've
added it to you batadv interface? Or that the vxlan interface didn't set the
correct needed_headroom for its lower_dev (see vxlan_config_apply)?
If you have the "slow" setup, can you please do following steps:
* keep vxlan as is (I hope you specify a fixed lowerdev)
- but try to print the needed headroom in vxlan_config_apply and compare it
to the ones from vxlan_build_skb
* remove the vxlan from your batadv interface
* add your vxlan again from the batadv interface
- check if the headroom numbers are now looking better in
batadv_hardif_recalc_extra_skbroom
* remove batadv interface from the bridge
* add your batadv interface again to the bridge
- is update_headroom() now using the correct headroom information?
> If you need any more input we are happy to help. Because the actual performance with running batman over vxlan is really bad.
> We have some figures here: https://gist.github.com/fadenb/9705059cf17eddf60e744e95bf926f05
Kind regards,
SvenAttachment:
signature.asc
Description: This is a digitally signed message part.
