All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [PATCH v2] batman-adv: add dynamic, bridged-in TT VID detection support
Date: Sat, 13 Jul 2024 00:13:54 +0200	[thread overview]
Message-ID: <ZpGqot-13tFMWrQW@sellars> (raw)
In-Reply-To: <Zm9NPkUOQuj93BQs@sellars>

And one more thought/idea that just came to my mind:

Maybe after adding dynamic VLAN detection from traffic we
could then also exclude the annoying, actually typically
unused VID 0 from the static addition? That way we would
save quite a bit of overhead as each VLAN currently quite
significantly increases the OGM size.

So basically thinking of simply adding a "if (!vid) return" to
(.ndo_vlan_rx_add_vid =) batadv_interface_add_vid().

One could still use VID 0 on bat0, it just wouldn't be detected as
quickly/immediately, would take an actual payload packet to be added.

Currently VID 0 is added because we set
"dev->features |= NETIF_F_HW_VLAN_CTAG_FILTER" in
batadv_softif_init_early(). Which in turn triggers:
net/8021q/vlan.c:vlan_device_event()->vlan_vid_add(dev, htons(ETH_P_8021Q), 0)
And triggers the message "adding VLAN 0 to HW filter on device bat0"
in dmesg.


But of course, first the BLA induced 30 seconds broadcast
filtering with each added VLAN would need to be solved. As that
might be a too easy DoS potential, I guess?
Could still need some feedback on how to best solve that
(bat_priv->bla.num_requests per VLAN?).

Regards, Linus

  reply	other threads:[~2024-07-12 22:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-12 21:39 [PATCH v2] batman-adv: add dynamic, bridged-in TT VID detection support Linus Lüssing
2024-06-16 20:38 ` Linus Lüssing
2024-07-12 22:13   ` Linus Lüssing [this message]
2024-11-14 13:48 ` Nicolas Escande
2024-11-14 13:58   ` Sven Eckelmann
2024-11-14 14:53     ` Nicolas Escande
2024-11-14 18:06       ` Linus Lüssing
2024-11-21 15:10         ` Nicolas Escande
2024-11-24  9:47     ` Sven Eckelmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZpGqot-13tFMWrQW@sellars \
    --to=linus.luessing@c0d3.blue \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.