Skip to contentSkip to conversation

802.1q HW filter spammage in 3.7.2+ kernels.

PATCH Applied Ben Greear 3 participants 6 messages Jan 16, 2013 – Jan 17, 2013

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Ben Greear

author
#0 lore raw

My kernel logs are full of this (I have 2000 macvlans).

Is this really worth logging?

8021q: adding VLAN 0 to HW filter on device eth3#364 8021q: adding VLAN 0 to HW filter on device eth3#384 8021q: adding VLAN 0 to HW filter on device eth3#434 8021q: adding VLAN 0 to HW filter on device eth3#304 8021q: adding VLAN 0 to HW filter on device eth3#242 8021q: adding VLAN 0 to HW filter on device eth3#312 8021q: adding VLAN 0 to HW filter on device eth3#512 8021q: adding VLAN 0 to HW filter on device eth2#481 8021q: adding VLAN 0 to HW filter on device eth3#262 8021q: adding VLAN 0 to HW filter on device eth3#282

Thanks,
Ben

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
#1 lore raw

From: Eric Dumazet <[email protected]>

Quoted 1 line · Ben Greear

My kernel logs are full of this (I have 2000 macvlans).

Are you using 2000 macvlans on the same device ? Interesting...

I am wondering how multicast/broadcast messages don't generate a huge load and packet drops, since we clone packets for every macvlan, and queue then to netif_rx()

I guess you dont use IPv6 on these macvlans ?

While reviewing the code, I found this small bug.

[PATCH] macvlan: fix macvlan_get_size()

Signed-off-by Eric Dumazet <[email protected]>
---
 drivers/net/macvlan.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/net/macvlan.c +6 -1
index 1047e58..f4f2790 100644
@@ -828,7 +828,12 @@ static int macvlan_changelink(struct net_device *dev,
 
 static size_t macvlan_get_size(const struct net_device *dev)
 {
-	return nla_total_size(4);
+	return
+		/* IFLA_MACVLAN_MODE, */
+		nla_total_size(4) +
+		/* IFLA_MACVLAN_FLAGS */
+		nla_total_size(2) +
+		0;
 }
 
 static int macvlan_fill_info(struct sk_buff *skb,
maintainer
#2 lore raw

From: Eric Dumazet <[email protected]>
Date: Tue, 15 Jan 2013 22:01:48 -0800

drivers/net/macvlan.c static int macvlan_changelink(struct net_device *dev, · line 836

Quoted 11 lines
drivers/net/macvlan.c +6 -1
@@ -828,7 +828,12 @@ static int macvlan_changelink(struct net_device *dev,
 
 static size_t macvlan_get_size(const struct net_device *dev)
 {
-	return nla_total_size(4);
+	return
+		/* IFLA_MACVLAN_MODE, */
+		nla_total_size(4) +
+		/* IFLA_MACVLAN_FLAGS */
+		nla_total_size(2) +
+		0;

Maybe:

	return (nla_total_size(4) + /* IFLA_MACVLAN_MODE, */
		nla_total_size(2) + /* IFLA_MACVLAN_FLAGS */
		0);
#3 lore raw

PATCH 1/1 macvlan: fix macvlan_get_size()

From: Eric Dumazet <[email protected]>

commit df8ef8f3aaa (macvlan: add FDB bridge ops and macvlan flags) forgot to update macvlan_get_size() after the addition of IFLA_MACVLAN_FLAGS

Signed-off-by Eric Dumazet <[email protected]>
Cc John Fastabend <[email protected]>
---
 drivers/net/macvlan.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/macvlan.c +4 -1
index 1047e58..7b44ebd 100644
@@ -828,7 +828,10 @@ static int macvlan_changelink(struct net_device *dev,
 
 static size_t macvlan_get_size(const struct net_device *dev)
 {
-	return nla_total_size(4);
+	return (0
+		+ nla_total_size(4) /* IFLA_MACVLAN_MODE */
+		+ nla_total_size(2) /* IFLA_MACVLAN_FLAGS */
+		);
 }
 
 static int macvlan_fill_info(struct sk_buff *skb,
author
#5 lore raw
In reply to Eric Dumazet
Quoted 6 lines · Eric Dumazet

From: Eric Dumazet <[email protected]>

Quoted 1 line · Ben Greear

My kernel logs are full of this (I have 2000 macvlans).

Are you using 2000 macvlans on the same device ? Interesting...

Well, in this case, we have 1000 mac-vlans on each of 2 1G Ethernet ports, but 2000 on a single device has been used as well.

Quoted 5 lines

I am wondering how multicast/broadcast messages don't generate a huge load and packet drops, since we clone packets for every macvlan, and queue then to netif_rx()

I have added ARP patches to do a random retry timer to help spread out the ARP requests a bit, at least. The system is still sluggish at times, but it does function. With a fixed-interval ARP timer, things can get into very bad patterns.

http://patchwork.ozlabs.org/patch/9301/

My test cases often require SO_BINDTODEVICE to function with full features, with one traffic-application per interface, so mac-vlans seems the easiest way to scale.

Quoted 1 line

I guess you dont use IPv6 on these macvlans ?

I have...but many use cases use far fewer (virtual) interfaces.

Thanks,
Ben

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com