[PATCH net-next] net: dropreason: add SKB_DROP_REASON_{BROAD,MULTI}CAST_BACKLOG

[PATCH net-next] net: dropreason: add SKB_DROP_REASON_{BROAD,MULTI}CAST_BACKLOG

[Eric Dumazet]

ipvlan and macvlan use queues to process broadcast or multicast packets
from a work queue.

Under attack these queues can drop packets.

Add BROADCAST_BACKLOG drop_reason for macvlan broadcast queue.

Add MULTICAST_BACKLOG drop_reason for ipvlan multicast queue.

Also change ipvlan_rcv_frame() to use SKB_DROP_REASON_DEV_READY
when the device is not UP.

Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 drivers/net/ipvlan/ipvlan_core.c |  4 ++--
 drivers/net/macvlan.c            |  2 +-
 include/net/dropreason-core.h    | 12 ++++++++++++
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
index 68fdb42068d0060c67d751b869a059e8cb1b6bd1..162e08200012ef272d9b1aee09ab54e724c9bc71 100644
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -337,7 +337,7 @@ static int ipvlan_rcv_frame(struct ipvl_addr *addr, struct sk_buff **pskb,
 	 */
 	if (local) {
 		if (unlikely(!(dev->flags & IFF_UP))) {
-			kfree_skb(skb);
+			kfree_skb_reason(skb, SKB_DROP_REASON_DEV_READY);
 			goto out;
 		}
 
@@ -596,7 +596,7 @@ static void ipvlan_multicast_enqueue(struct ipvl_port *port,
 	} else {
 		spin_unlock(&port->backlog.lock);
 		dev_core_stats_rx_dropped_inc(skb->dev);
-		kfree_skb(skb);
+		kfree_skb_reason(skb, SKB_DROP_REASON_MULTICAST_BACKLOG);
 	}
 }
 
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 54c514acacc5e24fcdb88904f41fd1d29b1e34d0..6c9f6fe3b5c08ae86a79af790fdbc6699aebf435 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -386,7 +386,7 @@ static void macvlan_broadcast_enqueue(struct macvlan_port *port,
 	return;
 
 free_nskb:
-	kfree_skb(nskb);
+	kfree_skb_reason(nskb, SKB_DROP_REASON_BROADCAST_BACKLOG);
 err:
 	dev_core_stats_rx_dropped_inc(skb->dev);
 }
diff --git a/include/net/dropreason-core.h b/include/net/dropreason-core.h
index de61dd5dbfd9dc7d91d22d79a510d42fb69eb60a..e81e7ae8b3271ba1a947104339bbc9e440f189f5 100644
--- a/include/net/dropreason-core.h
+++ b/include/net/dropreason-core.h
@@ -69,6 +69,8 @@
 	FN(QDISC_DROP)			\
 	FN(QDISC_BURST_DROP)		\
 	FN(CPU_BACKLOG)			\
+	FN(BROADCAST_BACKLOG)		\
+	FN(MULTICAST_BACKLOG)		\
 	FN(XDP)				\
 	FN(TC_INGRESS)			\
 	FN(UNHANDLED_PROTO)		\
@@ -382,6 +384,16 @@ enum skb_drop_reason {
 	 * netdev_max_backlog in net.rst) or RPS flow limit
 	 */
 	SKB_DROP_REASON_CPU_BACKLOG,
+	/**
+	 * @SKB_DROP_REASON_BROADCAST_BACKLOG: failed to enqueue the skb
+	 * to macvlan broadcast queue.
+	 */
+	SKB_DROP_REASON_BROADCAST_BACKLOG,
+	/**
+	 * @SKB_DROP_REASON_MULTICAST_BACKLOG: failed to enqueue the skb
+	 * to ipvlan multicast queue.
+	 */
+	SKB_DROP_REASON_MULTICAST_BACKLOG,
 	/** @SKB_DROP_REASON_XDP: dropped by XDP in input path */
 	SKB_DROP_REASON_XDP,
 	/** @SKB_DROP_REASON_TC_INGRESS: dropped in TC ingress HOOK */
-- 
2.53.0.1213.gd9a14994de-goog

Re: [PATCH net-next] net: dropreason: add SKB_DROP_REASON_{BROAD,MULTI}CAST_BACKLOG

[Simon Horman]

On Fri, Apr 03, 2026 at 02:24:43AM +0000, Eric Dumazet wrote:
> ipvlan and macvlan use queues to process broadcast or multicast packets
> from a work queue.
> 
> Under attack these queues can drop packets.
> 
> Add BROADCAST_BACKLOG drop_reason for macvlan broadcast queue.
> 
> Add MULTICAST_BACKLOG drop_reason for ipvlan multicast queue.
> 
> Also change ipvlan_rcv_frame() to use SKB_DROP_REASON_DEV_READY
> when the device is not UP.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Reviewed-by: Simon Horman <horms@kernel.org>

Re: [PATCH net-next] net: dropreason: add SKB_DROP_REASON_{BROAD,MULTI}CAST_BACKLOG

[Joe Damato]

On Fri, Apr 03, 2026 at 02:24:43AM +0000, Eric Dumazet wrote:
> ipvlan and macvlan use queues to process broadcast or multicast packets
> from a work queue.
> 
> Under attack these queues can drop packets.
> 
> Add BROADCAST_BACKLOG drop_reason for macvlan broadcast queue.
> 
> Add MULTICAST_BACKLOG drop_reason for ipvlan multicast queue.
> 
> Also change ipvlan_rcv_frame() to use SKB_DROP_REASON_DEV_READY
> when the device is not UP.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
>  drivers/net/ipvlan/ipvlan_core.c |  4 ++--
>  drivers/net/macvlan.c            |  2 +-
>  include/net/dropreason-core.h    | 12 ++++++++++++
>  3 files changed, 15 insertions(+), 3 deletions(-)

Reviewed-by: Joe Damato <joe@dama.to>

Re: [PATCH net-next] net: dropreason: add SKB_DROP_REASON_{BROAD,MULTI}CAST_BACKLOG

[Jakub Kicinski]

On Fri,  3 Apr 2026 02:24:43 +0000 Eric Dumazet wrote:
> ipvlan and macvlan use queues to process broadcast or multicast packets
> from a work queue.
> 
> Under attack these queues can drop packets.
> 
> Add BROADCAST_BACKLOG drop_reason for macvlan broadcast queue.
> 
> Add MULTICAST_BACKLOG drop_reason for ipvlan multicast queue.

What distinction are you trying to communicate by using BROADCAST 
vs MULTICAST? Funny naming of the functions aside I believe that
in both cases we're basically dealing with multicast traffic.
Reading the code it seems like macvlan has some optimization where
it delivers the frame inline if the multicast group is not very
popular. And if it is popular it schedules a work (and calls that
broadcast). ipvlan doesn't have the inline filter and calls the
deliver via work multicast.

tl;dr I think the drivers do the same thing just call their functions
broadcast vs multicast. Having two drop reasons here is actively
misleading?
-- 
pw-bot: cr

Re: [PATCH net-next] net: dropreason: add SKB_DROP_REASON_{BROAD,MULTI}CAST_BACKLOG

[Eric Dumazet]

On Mon, Apr 6, 2026 at 6:02 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri,  3 Apr 2026 02:24:43 +0000 Eric Dumazet wrote:
> > ipvlan and macvlan use queues to process broadcast or multicast packets
> > from a work queue.
> >
> > Under attack these queues can drop packets.
> >
> > Add BROADCAST_BACKLOG drop_reason for macvlan broadcast queue.
> >
> > Add MULTICAST_BACKLOG drop_reason for ipvlan multicast queue.
>
> What distinction are you trying to communicate by using BROADCAST
> vs MULTICAST? Funny naming of the functions aside I believe that
> in both cases we're basically dealing with multicast traffic.
> Reading the code it seems like macvlan has some optimization where
> it delivers the frame inline if the multicast group is not very
> popular. And if it is popular it schedules a work (and calls that
> broadcast). ipvlan doesn't have the inline filter and calls the
> deliver via work multicast.
>
> tl;dr I think the drivers do the same thing just call their functions
> broadcast vs multicast. Having two drop reasons here is actively
> misleading?

My intent was to differentiate ipvlan and macvlan reasons, some
deployments use both.

I can rename the reasons if you think this is better.

IPVLAN_MULTICAST_BACKLOG

MACVLAN_BROADCAST_BACKLOG

Re: [PATCH net-next] net: dropreason: add SKB_DROP_REASON_{BROAD,MULTI}CAST_BACKLOG

[Jakub Kicinski]

On Tue, 7 Apr 2026 03:09:41 -0700 Eric Dumazet wrote:
> On Mon, Apr 6, 2026 at 6:02 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > On Fri,  3 Apr 2026 02:24:43 +0000 Eric Dumazet wrote:  
> > > ipvlan and macvlan use queues to process broadcast or multicast packets
> > > from a work queue.
> > >
> > > Under attack these queues can drop packets.
> > >
> > > Add BROADCAST_BACKLOG drop_reason for macvlan broadcast queue.
> > >
> > > Add MULTICAST_BACKLOG drop_reason for ipvlan multicast queue.  
> >
> > What distinction are you trying to communicate by using BROADCAST
> > vs MULTICAST? Funny naming of the functions aside I believe that
> > in both cases we're basically dealing with multicast traffic.
> > Reading the code it seems like macvlan has some optimization where
> > it delivers the frame inline if the multicast group is not very
> > popular. And if it is popular it schedules a work (and calls that
> > broadcast). ipvlan doesn't have the inline filter and calls the
> > deliver via work multicast.
> >
> > tl;dr I think the drivers do the same thing just call their functions
> > broadcast vs multicast. Having two drop reasons here is actively
> > misleading?  
> 
> My intent was to differentiate ipvlan and macvlan reasons, some
> deployments use both.
> 
> I can rename the reasons if you think this is better.
> 
> IPVLAN_MULTICAST_BACKLOG
> 
> MACVLAN_BROADCAST_BACKLOG

Sounds better, thanks