[PATCH net-next] udp: add drop count for packets in udp_prod_queue

[PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

This commit adds SNMP drop count increment for the packets in
per NUMA queues which were introduced in commit b650bf0977d3
("udp: remove busylock and add per NUMA queues"). note that SNMP
counters are incremented currently by the caller for skb. And
that these skbs on the intermediate queue cannot be counted
there so need similar logic in their error path.

Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
---
v6:
  - increasing a single counter based on socket family
v5: https://lore.kernel.org/netdev/20260122185357.50922-1-mahdifrmx@gmail.com/
  - check if drop counts are non-zero before increasing countrers
v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
  - move all changes to unlikely(to_drop) branch
v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
  - remove the unreachable UDP_MIB_RCVBUFERRORS code
v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
  - change ENOMEM to ENOBUFS
v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
---
 net/ipv4/udp.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index ffe074cb5..dd302f5fb 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1797,10 +1797,13 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 			skb = to_drop;
 			to_drop = skb->next;
 			skb_mark_not_on_list(skb);
-			/* TODO: update SNMP values. */
 			sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
 		}
 		numa_drop_add(&udp_sk(sk)->drop_counters, nb);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, (sk->sk_family == PF_INET)),
+			       UDP_MIB_MEMERRORS, nb);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, (sk->sk_family == PF_INET)),
+			       UDP_MIB_INERRORS, nb);
 	}
 
 	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
-- 
2.34.1

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Eric Dumazet]

On Wed, Jan 28, 2026 at 8:03 AM Mahdi Faramarzpour <mahdifrmx@gmail.com> wrote:
>
> This commit adds SNMP drop count increment for the packets in
> per NUMA queues which were introduced in commit b650bf0977d3
> ("udp: remove busylock and add per NUMA queues"). note that SNMP
> counters are incremented currently by the caller for skb. And
> that these skbs on the intermediate queue cannot be counted
> there so need similar logic in their error path.
>
> Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
> ---
> v6:
>   - increasing a single counter based on socket family
> v5: https://lore.kernel.org/netdev/20260122185357.50922-1-mahdifrmx@gmail.com/
>   - check if drop counts are non-zero before increasing countrers
> v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
>   - move all changes to unlikely(to_drop) branch
> v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
>   - remove the unreachable UDP_MIB_RCVBUFERRORS code
> v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
>   - change ENOMEM to ENOBUFS
> v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
> ---
>  net/ipv4/udp.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index ffe074cb5..dd302f5fb 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1797,10 +1797,13 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
>                         skb = to_drop;
>                         to_drop = skb->next;
>                         skb_mark_not_on_list(skb);
> -                       /* TODO: update SNMP values. */
>                         sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
>                 }
>                 numa_drop_add(&udp_sk(sk)->drop_counters, nb);
> +               SNMP_ADD_STATS(__UDPX_MIB(sk, (sk->sk_family == PF_INET)),
> +                              UDP_MIB_MEMERRORS, nb);
> +               SNMP_ADD_STATS(__UDPX_MIB(sk, (sk->sk_family == PF_INET)),
> +                              UDP_MIB_INERRORS, nb);
>         }

Hmm.. I have not followed your prior attempts, sorry for coming late.

Note that an UDP AF_INET6 socket for which ipv6_only_sock(sk) is false
can receive
IPv4 and IPv6 UDP packets, if bound to any addresses.

The to_drop list could contain a mix of IPv4 and IPv6 packets.

Ideally we should track SNMP values in the proper space (Ipv4 , IPv6).

See IPV6_V6ONLY and /proc/sys/net/ipv6/bindv6only for reference.

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

On Wed, Jan 28, 2026 at 3:14 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Wed, Jan 28, 2026 at 8:03 AM Mahdi Faramarzpour <mahdifrmx@gmail.com> wrote:
> >
> > This commit adds SNMP drop count increment for the packets in
> > per NUMA queues which were introduced in commit b650bf0977d3
> > ("udp: remove busylock and add per NUMA queues"). note that SNMP
> > counters are incremented currently by the caller for skb. And
> > that these skbs on the intermediate queue cannot be counted
> > there so need similar logic in their error path.
> >
> > Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
> > ---
> > v6:
> >   - increasing a single counter based on socket family
> > v5: https://lore.kernel.org/netdev/20260122185357.50922-1-mahdifrmx@gmail.com/
> >   - check if drop counts are non-zero before increasing countrers
> > v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
> >   - move all changes to unlikely(to_drop) branch
> > v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
> >   - remove the unreachable UDP_MIB_RCVBUFERRORS code
> > v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
> >   - change ENOMEM to ENOBUFS
> > v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
> > ---
> >  net/ipv4/udp.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > index ffe074cb5..dd302f5fb 100644
> > --- a/net/ipv4/udp.c
> > +++ b/net/ipv4/udp.c
> > @@ -1797,10 +1797,13 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
> >                         skb = to_drop;
> >                         to_drop = skb->next;
> >                         skb_mark_not_on_list(skb);
> > -                       /* TODO: update SNMP values. */
> >                         sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
> >                 }
> >                 numa_drop_add(&udp_sk(sk)->drop_counters, nb);
> > +               SNMP_ADD_STATS(__UDPX_MIB(sk, (sk->sk_family == PF_INET)),
> > +                              UDP_MIB_MEMERRORS, nb);
> > +               SNMP_ADD_STATS(__UDPX_MIB(sk, (sk->sk_family == PF_INET)),
> > +                              UDP_MIB_INERRORS, nb);
> >         }
>
> Hmm.. I have not followed your prior attempts, sorry for coming late.
>
> Note that an UDP AF_INET6 socket for which ipv6_only_sock(sk) is false
> can receive
> IPv4 and IPv6 UDP packets, if bound to any addresses.
>
> The to_drop list could contain a mix of IPv4 and IPv6 packets.
>
> Ideally we should track SNMP values in the proper space (Ipv4 , IPv6).
>
> See IPV6_V6ONLY and /proc/sys/net/ipv6/bindv6only for reference.
This is the exact discussion I had with Willem de Bruijn:
https://lore.kernel.org/netdev/willemdebruijn.kernel.17f36003699cb@gmail.com/

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Eric Dumazet]

On Wed, Jan 28, 2026 at 1:27 PM Mahdi Faramarzpour <mahdifrmx@gmail.com> wrote:
>
> On Wed, Jan 28, 2026 at 3:14 PM Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Wed, Jan 28, 2026 at 8:03 AM Mahdi Faramarzpour <mahdifrmx@gmail.com> wrote:
> > >
> > > This commit adds SNMP drop count increment for the packets in
> > > per NUMA queues which were introduced in commit b650bf0977d3
> > > ("udp: remove busylock and add per NUMA queues"). note that SNMP
> > > counters are incremented currently by the caller for skb. And
> > > that these skbs on the intermediate queue cannot be counted
> > > there so need similar logic in their error path.
> > >
> > > Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
> > > ---
> > > v6:
> > >   - increasing a single counter based on socket family
> > > v5: https://lore.kernel.org/netdev/20260122185357.50922-1-mahdifrmx@gmail.com/
> > >   - check if drop counts are non-zero before increasing countrers
> > > v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
> > >   - move all changes to unlikely(to_drop) branch
> > > v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
> > >   - remove the unreachable UDP_MIB_RCVBUFERRORS code
> > > v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
> > >   - change ENOMEM to ENOBUFS
> > > v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
> > > ---
> > >  net/ipv4/udp.c | 5 ++++-
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > > index ffe074cb5..dd302f5fb 100644
> > > --- a/net/ipv4/udp.c
> > > +++ b/net/ipv4/udp.c
> > > @@ -1797,10 +1797,13 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
> > >                         skb = to_drop;
> > >                         to_drop = skb->next;
> > >                         skb_mark_not_on_list(skb);
> > > -                       /* TODO: update SNMP values. */
> > >                         sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
> > >                 }
> > >                 numa_drop_add(&udp_sk(sk)->drop_counters, nb);
> > > +               SNMP_ADD_STATS(__UDPX_MIB(sk, (sk->sk_family == PF_INET)),
> > > +                              UDP_MIB_MEMERRORS, nb);
> > > +               SNMP_ADD_STATS(__UDPX_MIB(sk, (sk->sk_family == PF_INET)),
> > > +                              UDP_MIB_INERRORS, nb);
> > >         }
> >
> > Hmm.. I have not followed your prior attempts, sorry for coming late.
> >
> > Note that an UDP AF_INET6 socket for which ipv6_only_sock(sk) is false
> > can receive
> > IPv4 and IPv6 UDP packets, if bound to any addresses.
> >
> > The to_drop list could contain a mix of IPv4 and IPv6 packets.
> >
> > Ideally we should track SNMP values in the proper space (Ipv4 , IPv6).
> >
> > See IPV6_V6ONLY and /proc/sys/net/ipv6/bindv6only for reference.
> This is the exact discussion I had with Willem de Bruijn:
> https://lore.kernel.org/netdev/willemdebruijn.kernel.17f36003699cb@gmail.com/

I think Willem was wrong :)

__udp_enqueue_schedule_skb() is called either from
__udp_queue_rcv_skb() for IPv4 packets,
or __udpv6_queue_rcv_skb() for IPv6 packets, and they both can feed
packets to a single and shared UDP socket.

An IPv4 packet will not go through __udpv6_queue_rcv_skb().

It would be deceptive to increment IPV6 UDP counters if a host only
receives IPv4 UDP packets.

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

On Wed, Jan 28, 2026 at 4:07 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Wed, Jan 28, 2026 at 1:27 PM Mahdi Faramarzpour <mahdifrmx@gmail.com> wrote:
> >
> > On Wed, Jan 28, 2026 at 3:14 PM Eric Dumazet <edumazet@google.com> wrote:
> > >
> > > On Wed, Jan 28, 2026 at 8:03 AM Mahdi Faramarzpour <mahdifrmx@gmail.com> wrote:
> > > >
> > > > This commit adds SNMP drop count increment for the packets in
> > > > per NUMA queues which were introduced in commit b650bf0977d3
> > > > ("udp: remove busylock and add per NUMA queues"). note that SNMP
> > > > counters are incremented currently by the caller for skb. And
> > > > that these skbs on the intermediate queue cannot be counted
> > > > there so need similar logic in their error path.
> > > >
> > > > Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
> > > > ---
> > > > v6:
> > > >   - increasing a single counter based on socket family
> > > > v5: https://lore.kernel.org/netdev/20260122185357.50922-1-mahdifrmx@gmail.com/
> > > >   - check if drop counts are non-zero before increasing countrers
> > > > v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
> > > >   - move all changes to unlikely(to_drop) branch
> > > > v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
> > > >   - remove the unreachable UDP_MIB_RCVBUFERRORS code
> > > > v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
> > > >   - change ENOMEM to ENOBUFS
> > > > v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
> > > > ---
> > > >  net/ipv4/udp.c | 5 ++++-
> > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > > > index ffe074cb5..dd302f5fb 100644
> > > > --- a/net/ipv4/udp.c
> > > > +++ b/net/ipv4/udp.c
> > > > @@ -1797,10 +1797,13 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
> > > >                         skb = to_drop;
> > > >                         to_drop = skb->next;
> > > >                         skb_mark_not_on_list(skb);
> > > > -                       /* TODO: update SNMP values. */
> > > >                         sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
> > > >                 }
> > > >                 numa_drop_add(&udp_sk(sk)->drop_counters, nb);
> > > > +               SNMP_ADD_STATS(__UDPX_MIB(sk, (sk->sk_family == PF_INET)),
> > > > +                              UDP_MIB_MEMERRORS, nb);
> > > > +               SNMP_ADD_STATS(__UDPX_MIB(sk, (sk->sk_family == PF_INET)),
> > > > +                              UDP_MIB_INERRORS, nb);
> > > >         }
> > >
> > > Hmm.. I have not followed your prior attempts, sorry for coming late.
> > >
> > > Note that an UDP AF_INET6 socket for which ipv6_only_sock(sk) is false
> > > can receive
> > > IPv4 and IPv6 UDP packets, if bound to any addresses.
> > >
> > > The to_drop list could contain a mix of IPv4 and IPv6 packets.
> > >
> > > Ideally we should track SNMP values in the proper space (Ipv4 , IPv6).
> > >
> > > See IPV6_V6ONLY and /proc/sys/net/ipv6/bindv6only for reference.
> > This is the exact discussion I had with Willem de Bruijn:
> > https://lore.kernel.org/netdev/willemdebruijn.kernel.17f36003699cb@gmail.com/
>
> I think Willem was wrong :)
>
> __udp_enqueue_schedule_skb() is called either from
> __udp_queue_rcv_skb() for IPv4 packets,
> or __udpv6_queue_rcv_skb() for IPv6 packets, and they both can feed
> packets to a single and shared UDP socket.
>
> An IPv4 packet will not go through __udpv6_queue_rcv_skb().
>
> It would be deceptive to increment IPV6 UDP counters if a host only
> receives IPv4 UDP packets.
Ok, in case other people wonder which logic is in fact true, refer to
net/core/dev.c in which
netif_receive_skb is defined that's called from device drivers. This
routine checks the packet
against a list of struct packet_types, ultimately finding the matched
type and calling its
registered func field, that are ip_rcv & ip6_rcv in case of the two
ipv4 & ipv6 types. So, the
appropriate routine is chosen based on packet type, not socket family.

That being said, I think the previous patch was just fine, unless
Willem wants the newline
after variable declarations:
https://lore.kernel.org/netdev/20260122185357.50922-1-mahdifrmx@gmail.com/

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Willem de Bruijn]

Mahdi Faramarzpour wrote:
> On Wed, Jan 28, 2026 at 4:07 PM Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Wed, Jan 28, 2026 at 1:27 PM Mahdi Faramarzpour <mahdifrmx@gmail.com> wrote:
> > >
> > > On Wed, Jan 28, 2026 at 3:14 PM Eric Dumazet <edumazet@google.com> wrote:
> > > >
> > > > On Wed, Jan 28, 2026 at 8:03 AM Mahdi Faramarzpour <mahdifrmx@gmail.com> wrote:
> > > > >
> > > > > This commit adds SNMP drop count increment for the packets in
> > > > > per NUMA queues which were introduced in commit b650bf0977d3
> > > > > ("udp: remove busylock and add per NUMA queues"). note that SNMP
> > > > > counters are incremented currently by the caller for skb. And
> > > > > that these skbs on the intermediate queue cannot be counted
> > > > > there so need similar logic in their error path.
> > > > >
> > > > > Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
> > > > > ---
> > > > > v6:
> > > > >   - increasing a single counter based on socket family
> > > > > v5: https://lore.kernel.org/netdev/20260122185357.50922-1-mahdifrmx@gmail.com/
> > > > >   - check if drop counts are non-zero before increasing countrers
> > > > > v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
> > > > >   - move all changes to unlikely(to_drop) branch
> > > > > v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
> > > > >   - remove the unreachable UDP_MIB_RCVBUFERRORS code
> > > > > v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
> > > > >   - change ENOMEM to ENOBUFS
> > > > > v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
> > > > > ---
> > > > >  net/ipv4/udp.c | 5 ++++-
> > > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > > > > index ffe074cb5..dd302f5fb 100644
> > > > > --- a/net/ipv4/udp.c
> > > > > +++ b/net/ipv4/udp.c
> > > > > @@ -1797,10 +1797,13 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
> > > > >                         skb = to_drop;
> > > > >                         to_drop = skb->next;
> > > > >                         skb_mark_not_on_list(skb);
> > > > > -                       /* TODO: update SNMP values. */
> > > > >                         sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
> > > > >                 }
> > > > >                 numa_drop_add(&udp_sk(sk)->drop_counters, nb);
> > > > > +               SNMP_ADD_STATS(__UDPX_MIB(sk, (sk->sk_family == PF_INET)),
> > > > > +                              UDP_MIB_MEMERRORS, nb);
> > > > > +               SNMP_ADD_STATS(__UDPX_MIB(sk, (sk->sk_family == PF_INET)),
> > > > > +                              UDP_MIB_INERRORS, nb);
> > > > >         }
> > > >
> > > > Hmm.. I have not followed your prior attempts, sorry for coming late.
> > > >
> > > > Note that an UDP AF_INET6 socket for which ipv6_only_sock(sk) is false
> > > > can receive
> > > > IPv4 and IPv6 UDP packets, if bound to any addresses.
> > > >
> > > > The to_drop list could contain a mix of IPv4 and IPv6 packets.
> > > >
> > > > Ideally we should track SNMP values in the proper space (Ipv4 , IPv6).
> > > >
> > > > See IPV6_V6ONLY and /proc/sys/net/ipv6/bindv6only for reference.
> > > This is the exact discussion I had with Willem de Bruijn:
> > > https://lore.kernel.org/netdev/willemdebruijn.kernel.17f36003699cb@gmail.com/
> >
> > I think Willem was wrong :)
> >
> > __udp_enqueue_schedule_skb() is called either from
> > __udp_queue_rcv_skb() for IPv4 packets,
> > or __udpv6_queue_rcv_skb() for IPv6 packets, and they both can feed
> > packets to a single and shared UDP socket.
> >
> > An IPv4 packet will not go through __udpv6_queue_rcv_skb().

Happy to be wrong :) Thanks for the correction.

> >
> > It would be deceptive to increment IPV6 UDP counters if a host only
> > receives IPv4 UDP packets.
> Ok, in case other people wonder which logic is in fact true, refer to
> net/core/dev.c in which
> netif_receive_skb is defined that's called from device drivers. This
> routine checks the packet
> against a list of struct packet_types, ultimately finding the matched
> type and calling its
> registered func field, that are ip_rcv & ip6_rcv in case of the two
> ipv4 & ipv6 types. So, the
> appropriate routine is chosen based on packet type, not socket family.
> 
> That being said, I think the previous patch was just fine, unless
> Willem wants the newline
> after variable declarations:
> https://lore.kernel.org/netdev/20260122185357.50922-1-mahdifrmx@gmail.com/


You'll have to resubmit anyway. Then please address the minor
stylistic point.

[PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

This commit adds SNMP drop count increment for the packets in
per NUMA queues which were introduced in commit b650bf0977d3
("udp: remove busylock and add per NUMA queues"). note that SNMP
counters are incremented currently by the caller for skb. And
that these skbs on the intermediate queue cannot be counted
there so need similar logic in their error path.

Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
---
v7:
  - revert the last change and fix style
v6: https://lore.kernel.org/netdev/20260128070311.48892-1-mahdifrmx@gmail.com/
  - increasing a single counter based on socket family
v5: https://lore.kernel.org/netdev/20260122185357.50922-1-mahdifrmx@gmail.com/
  - check if drop counts are non-zero before increasing countrers
v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
  - move all changes to unlikely(to_drop) branch
v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
  - remove the unreachable UDP_MIB_RCVBUFERRORS code
v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
  - change ENOMEM to ENOBUFS
v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
---
 net/ipv4/udp.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index ffe074cb5..6ad7296db 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1793,14 +1793,32 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 	}
 
 	if (unlikely(to_drop)) {
+		int err_ipv4 = 0;
+		int err_ipv6 = 0;
+
 		for (nb = 0; to_drop != NULL; nb++) {
 			skb = to_drop;
+			if (skb->protocol == htons(ETH_P_IP))
+				err_ipv4++;
+			else
+				err_ipv6++;
 			to_drop = skb->next;
 			skb_mark_not_on_list(skb);
-			/* TODO: update SNMP values. */
 			sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
 		}
 		numa_drop_add(&udp_sk(sk)->drop_counters, nb);
+		if (err_ipv4 > 0) {
+			SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS,
+				       err_ipv4);
+			SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS,
+				       err_ipv4);
+		}
+		if (err_ipv6 > 0) {
+			SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_MEMERRORS,
+				       err_ipv6);
+			SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_INERRORS,
+				       err_ipv6);
+		}
 	}
 
 	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
-- 
2.34.1

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Willem de Bruijn]

Mahdi Faramarzpour wrote:
> This commit adds SNMP drop count increment for the packets in
> per NUMA queues which were introduced in commit b650bf0977d3
> ("udp: remove busylock and add per NUMA queues"). note that SNMP
> counters are incremented currently by the caller for skb. And
> that these skbs on the intermediate queue cannot be counted
> there so need similar logic in their error path.
> 
> Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>

Reviewed-by: Willem de Bruijn <willemb@google.com>

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Eric Dumazet]

On Thu, Jan 29, 2026 at 6:17 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> Mahdi Faramarzpour wrote:
> > This commit adds SNMP drop count increment for the packets in
> > per NUMA queues which were introduced in commit b650bf0977d3
> > ("udp: remove busylock and add per NUMA queues"). note that SNMP
> > counters are incremented currently by the caller for skb. And
> > that these skbs on the intermediate queue cannot be counted
> > there so need similar logic in their error path.
> >
> > Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
>
> Reviewed-by: Willem de Bruijn <willemb@google.com>

Reviewed-by: Eric Dumazet <edumazet@google.com>

Thanks

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Thu, 29 Jan 2026 12:08:06 +0330 you wrote:
> This commit adds SNMP drop count increment for the packets in
> per NUMA queues which were introduced in commit b650bf0977d3
> ("udp: remove busylock and add per NUMA queues"). note that SNMP
> counters are incremented currently by the caller for skb. And
> that these skbs on the intermediate queue cannot be counted
> there so need similar logic in their error path.
> 
> [...]

Here is the summary with links:
  - [net-next] udp: add drop count for packets in udp_prod_queue
    https://git.kernel.org/netdev/net-next/c/820990d66577

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

[PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

This commit adds SNMP drop count increment for the packets in
per NUMA queues which were introduced in commit b650bf0977d3
("udp: remove busylock and add per NUMA queues"). note that SNMP
counters are incremented currently by the caller for skb. And
that these skbs on the intermediate queue cannot be counted
there so need similar logic in their error path.

Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
---
v5:
  - check if drop counts are non-zero before increasing countrers
v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
  - move all changes to unlikely(to_drop) branch
v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
  - remove the unreachable UDP_MIB_RCVBUFERRORS code
v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
  - change ENOMEM to ENOBUFS
v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
---
 net/ipv4/udp.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index ffe074cb5..41cf8f7ab 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1793,14 +1793,31 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 	}
 
 	if (unlikely(to_drop)) {
+		int err_ipv4 = 0;
+		int err_ipv6 = 0;
 		for (nb = 0; to_drop != NULL; nb++) {
 			skb = to_drop;
+			if (skb->protocol == htons(ETH_P_IP))
+				err_ipv4++;
+			else
+				err_ipv6++;
 			to_drop = skb->next;
 			skb_mark_not_on_list(skb);
-			/* TODO: update SNMP values. */
 			sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
 		}
 		numa_drop_add(&udp_sk(sk)->drop_counters, nb);
+		if (err_ipv4 > 0) {
+			SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS,
+				       err_ipv4);
+			SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS,
+				       err_ipv4);
+		}
+		if (err_ipv6 > 0) {
+			SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_MEMERRORS,
+				       err_ipv6);
+			SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_INERRORS,
+				       err_ipv6);
+		}
 	}
 
 	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
-- 
2.34.1

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Willem de Bruijn]

Mahdi Faramarzpour wrote:
> This commit adds SNMP drop count increment for the packets in
> per NUMA queues which were introduced in commit b650bf0977d3
> ("udp: remove busylock and add per NUMA queues"). note that SNMP
> counters are incremented currently by the caller for skb. And
> that these skbs on the intermediate queue cannot be counted
> there so need similar logic in their error path.
> 
> Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
> ---
> v5:
>   - check if drop counts are non-zero before increasing countrers
> v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
>   - move all changes to unlikely(to_drop) branch
> v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
>   - remove the unreachable UDP_MIB_RCVBUFERRORS code
> v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
>   - change ENOMEM to ENOBUFS
> v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
> ---
>  net/ipv4/udp.c | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index ffe074cb5..41cf8f7ab 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1793,14 +1793,31 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
>  	}
>  
>  	if (unlikely(to_drop)) {
> +		int err_ipv4 = 0;
> +		int err_ipv6 = 0;

nit: whitespace between variable definition and code block

>  		for (nb = 0; to_drop != NULL; nb++) {
>  			skb = to_drop;
> +			if (skb->protocol == htons(ETH_P_IP))
> +				err_ipv4++;
> +			else
> +				err_ipv6++;

No need for separate counters.

All counters will either update IPv4 or IPv6 stats. Similar to how
the caller of _udp_enqueue_schedule_sk is either __udp_queue_rcv_skb
or __udpv6_queue_rcv_skb and chooses the SNMP stat based on that.

Can check sk_family == PF_INET6 once.

>  			to_drop = skb->next;
>  			skb_mark_not_on_list(skb);
> -			/* TODO: update SNMP values. */
>  			sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
>  		}
>  		numa_drop_add(&udp_sk(sk)->drop_counters, nb);
> +		if (err_ipv4 > 0) {
> +			SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS,
> +				       err_ipv4);
> +			SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS,
> +				       err_ipv4);
> +		}
> +		if (err_ipv6 > 0) {
> +			SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_MEMERRORS,
> +				       err_ipv6);
> +			SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_INERRORS,
> +				       err_ipv6);
> +		}
>  	}
>  
>  	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
> -- 
> 2.34.1
> 

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Paolo Abeni]

On 1/22/26 10:26 PM, Willem de Bruijn wrote:
> Mahdi Faramarzpour wrote:
>> This commit adds SNMP drop count increment for the packets in
>> per NUMA queues which were introduced in commit b650bf0977d3
>> ("udp: remove busylock and add per NUMA queues"). note that SNMP
>> counters are incremented currently by the caller for skb. And
>> that these skbs on the intermediate queue cannot be counted
>> there so need similar logic in their error path.
>>
>> Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
>> ---
>> v5:
>>   - check if drop counts are non-zero before increasing countrers
>> v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
>>   - move all changes to unlikely(to_drop) branch
>> v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
>>   - remove the unreachable UDP_MIB_RCVBUFERRORS code
>> v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
>>   - change ENOMEM to ENOBUFS
>> v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
>> ---
>>  net/ipv4/udp.c | 19 ++++++++++++++++++-
>>  1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
>> index ffe074cb5..41cf8f7ab 100644
>> --- a/net/ipv4/udp.c
>> +++ b/net/ipv4/udp.c
>> @@ -1793,14 +1793,31 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
>>  	}
>>  
>>  	if (unlikely(to_drop)) {
>> +		int err_ipv4 = 0;
>> +		int err_ipv6 = 0;
> 
> nit: whitespace between variable definition and code block
> 
>>  		for (nb = 0; to_drop != NULL; nb++) {
>>  			skb = to_drop;
>> +			if (skb->protocol == htons(ETH_P_IP))
>> +				err_ipv4++;
>> +			else
>> +				err_ipv6++;
> 
> No need for separate counters.
> 
> All counters will either update IPv4 or IPv6 stats. Similar to how
> the caller of _udp_enqueue_schedule_sk is either __udp_queue_rcv_skb
> or __udpv6_queue_rcv_skb and chooses the SNMP stat based on that.
> 
> Can check sk_family == PF_INET6 once.

I think that doing the SNMP accounting in __udp_enqueue_schedule_skb()
(for `to_drop`), __udp_queue_rcv_skb() and __udpv6_queue_rcv_skb() (for
`skb`) is a little confusing and possible error prone in the long run.

I'm wondering if something alike the following (completely untested, not
even built! just to give the idea) would be better?

Note that the additional argument in __udp_enqueue_schedule_skb() could
be avoided piggybacking the `to_drop` return argument into the
__udp_enqueue_schedule_skb() return value.

---
diff --git a/include/net/udp.h b/include/net/udp.h
index a061d1b22ddc..673497eb79b7 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -399,7 +399,8 @@ static inline bool udp_sk_bound_dev_eq(const struct
net *net, int bound_dev_if,
 /* net/ipv4/udp.c */
 void udp_destruct_common(struct sock *sk);
 void skb_consume_udp(struct sock *sk, struct sk_buff *skb, int len);
-int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb);
+int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb,
+			       struct sk_buff *to_drop);
 void udp_skb_destructor(struct sock *sk, struct sk_buff *skb);
 struct sk_buff *__skb_recv_udp(struct sock *sk, unsigned int flags, int
*off,
 			       int *err);
@@ -411,6 +412,21 @@ static inline struct sk_buff *skb_recv_udp(struct
sock *sk, unsigned int flags,
 	return __skb_recv_udp(sk, flags, &off, err);
 }

+static inline int udp_drop_skbs(struct sock *sk, struct sk_buff *to_drop)
+{
+	struct sk_buff *skb;
+	int nb;
+
+	for (nb = 0; to_drop != NULL; nb++) {
+		skb = to_drop;
+		to_drop = skb->next;
+		skb_mark_not_on_list(skb);
+		sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
+	}
+	numa_drop_add(&udp_sk(sk)->drop_counters, nb);
+	return nb;
+}
+
 enum skb_drop_reason udp_v4_early_demux(struct sk_buff *skb);
 bool udp_sk_rx_dst_set(struct sock *sk, struct dst_entry *dst);
 int udp_err(struct sk_buff *, u32);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index ee63af0ef42c..0869e115c0d3 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1696,14 +1696,15 @@ static int udp_rmem_schedule(struct sock *sk,
int size)
 	return 0;
 }

-int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
+int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb,
+			       struct sk_buff **to_drop)
 {
 	struct sk_buff_head *list = &sk->sk_receive_queue;
 	struct udp_prod_queue *udp_prod_queue;
-	struct sk_buff *next, *to_drop = NULL;
 	struct llist_node *ll_list;
 	unsigned int rmem, rcvbuf;
 	int size, err = -ENOMEM;
+	struct sk_buff *next;
 	int total_size = 0;
 	int q_size = 0;
 	int dropcount;
@@ -1761,8 +1762,8 @@ int __udp_enqueue_schedule_skb(struct sock *sk,
struct sk_buff *skb)
 		err = udp_rmem_schedule(sk, size);
 		if (unlikely(err)) {
 			/*  Free the skbs outside of locked section. */
-			skb->next = to_drop;
-			to_drop = skb;
+			skb->next = *to_drop;
+			*to_drop = skb;
 			continue;
 		}

@@ -1792,17 +1793,6 @@ int __udp_enqueue_schedule_skb(struct sock *sk,
struct sk_buff *skb)
 		}
 	}

-	if (unlikely(to_drop)) {
-		for (nb = 0; to_drop != NULL; nb++) {
-			skb = to_drop;
-			to_drop = skb->next;
-			skb_mark_not_on_list(skb);
-			/* TODO: update SNMP values. */
-			sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
-		}
-		numa_drop_add(&udp_sk(sk)->drop_counters, nb);
-	}
-
 	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);

 	return 0;
@@ -2333,6 +2323,7 @@ void udp_v4_rehash(struct sock *sk)

 static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 {
+	struct sk_buff *to_drop = NULL;
 	int rc;

 	if (inet_sk(sk)->inet_daddr) {
@@ -2343,7 +2334,13 @@ static int __udp_queue_rcv_skb(struct sock *sk,
struct sk_buff *skb)
 		sk_mark_napi_id_once(sk, skb);
 	}

-	rc = __udp_enqueue_schedule_skb(sk, skb);
+	rc = __udp_enqueue_schedule_skb(sk, skb, &to_drop);
+	if (unlikely(to_drop)) {
+		int cnt = udp_drop_skb_list(sk, to_drop);
+
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS, cnt);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS, cnt);
+	}
 	if (rc < 0) {
 		int is_udplite = IS_UDPLITE(sk);
 		int drop_reason;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 794c13674e8a..5950ec699deb 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -782,6 +782,7 @@ int __udp6_lib_err(struct sk_buff *skb, struct
inet6_skb_parm *opt,

 static int __udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 {
+	struct sk_buff *to_drop = NULL;
 	int rc;

 	if (!ipv6_addr_any(&sk->sk_v6_daddr)) {
@@ -792,7 +793,13 @@ static int __udpv6_queue_rcv_skb(struct sock *sk,
struct sk_buff *skb)
 		sk_mark_napi_id_once(sk, skb);
 	}

-	rc = __udp_enqueue_schedule_skb(sk, skb);
+	rc = __udp_enqueue_schedule_skb(sk, skb, &to_drop);
+	if (unlikely(to_drop)) {
+		int cnt = udp_drop_skb_list(sk, to_drop);
+
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS, cnt);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS, cnt);
+	}
 	if (rc < 0) {
 		int is_udplite = IS_UDPLITE(sk);
 		enum skb_drop_reason drop_reason;

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Willem de Bruijn]

Paolo Abeni wrote:
> On 1/22/26 10:26 PM, Willem de Bruijn wrote:
> > Mahdi Faramarzpour wrote:
> >> This commit adds SNMP drop count increment for the packets in
> >> per NUMA queues which were introduced in commit b650bf0977d3
> >> ("udp: remove busylock and add per NUMA queues"). note that SNMP
> >> counters are incremented currently by the caller for skb. And
> >> that these skbs on the intermediate queue cannot be counted
> >> there so need similar logic in their error path.
> >>
> >> Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
> >> ---
> >> v5:
> >>   - check if drop counts are non-zero before increasing countrers
> >> v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
> >>   - move all changes to unlikely(to_drop) branch
> >> v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
> >>   - remove the unreachable UDP_MIB_RCVBUFERRORS code
> >> v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
> >>   - change ENOMEM to ENOBUFS
> >> v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
> >> ---
> >>  net/ipv4/udp.c | 19 ++++++++++++++++++-
> >>  1 file changed, 18 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> >> index ffe074cb5..41cf8f7ab 100644
> >> --- a/net/ipv4/udp.c
> >> +++ b/net/ipv4/udp.c
> >> @@ -1793,14 +1793,31 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
> >>  	}
> >>  
> >>  	if (unlikely(to_drop)) {
> >> +		int err_ipv4 = 0;
> >> +		int err_ipv6 = 0;
> > 
> > nit: whitespace between variable definition and code block
> > 
> >>  		for (nb = 0; to_drop != NULL; nb++) {
> >>  			skb = to_drop;
> >> +			if (skb->protocol == htons(ETH_P_IP))
> >> +				err_ipv4++;
> >> +			else
> >> +				err_ipv6++;
> > 
> > No need for separate counters.
> > 
> > All counters will either update IPv4 or IPv6 stats. Similar to how
> > the caller of _udp_enqueue_schedule_sk is either __udp_queue_rcv_skb
> > or __udpv6_queue_rcv_skb and chooses the SNMP stat based on that.
> > 
> > Can check sk_family == PF_INET6 once.
> 
> I think that doing the SNMP accounting in __udp_enqueue_schedule_skb()
> (for `to_drop`), __udp_queue_rcv_skb() and __udpv6_queue_rcv_skb() (for
> `skb`) is a little confusing and possible error prone in the long run.
> 
> I'm wondering if something alike the following (completely untested, not
> even built! just to give the idea) would be better?

I don't see the error prone issue with the simpler patch.
But SGTM if you prefer this.
 
> Note that the additional argument in __udp_enqueue_schedule_skb() could
> be avoided piggybacking the `to_drop` return argument into the
> __udp_enqueue_schedule_skb() return value.

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Paolo Abeni]

On 1/23/26 3:41 PM, Willem de Bruijn wrote:
> Paolo Abeni wrote:
>> I think that doing the SNMP accounting in __udp_enqueue_schedule_skb()
>> (for `to_drop`), __udp_queue_rcv_skb() and __udpv6_queue_rcv_skb() (for
>> `skb`) is a little confusing and possible error prone in the long run.
>>
>> I'm wondering if something alike the following (completely untested, not
>> even built! just to give the idea) would be better?
> 
> I don't see the error prone issue with the simpler patch.
> But SGTM if you prefer this.
It's not a big deal but if we need to update the UDP MIB someday having
to look in different places could cause missing something.

The code I proposed could be made smaller with something alike the
following (still completely untested), which in turn looks quite alike
what this patch is heading, I guess. So really it's not a big deal.
---
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 1db63db7e5d4..431de8dda0d3 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1793,6 +1795,7 @@ int __udp_enqueue_schedule_skb(struct sock *sk,
struct sk_buff *skb)
 		}
 	}

+	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
 	if (unlikely(to_drop)) {
 		for (nb = 0; to_drop != NULL; nb++) {
 			skb = to_drop;
@@ -1802,10 +1805,9 @@ int __udp_enqueue_schedule_skb(struct sock *sk,
struct sk_buff *skb)
 			sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
 		}
 		numa_drop_add(&udp_sk(sk)->drop_counters, nb);
+		return nb;
 	}

-	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
-
 	return 0;

 drop:
@@ -2345,6 +2347,9 @@ static int __udp_queue_rcv_skb(struct sock *sk,
struct sk_buff *skb)
 	}

 	rc = __udp_enqueue_schedule_skb(sk, skb);
+	if (likely(!rc))
+		return 0;
+
 	if (rc < 0) {
 		int is_udplite = IS_UDPLITE(sk);
 		int drop_reason;
@@ -2365,6 +2370,9 @@ static int __udp_queue_rcv_skb(struct sock *sk,
struct sk_buff *skb)
 		return -1;
 	}

+	/* rc > 0, packets dropped after dequeueing from prod_queue */
+	SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS, rc);
+	SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS, rc);
 	return 0;
 }

diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 010b909275dd..df895096669e 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -793,6 +793,9 @@ static int __udpv6_queue_rcv_skb(struct sock *sk,
struct sk_buff *skb)
 	}

 	rc = __udp_enqueue_schedule_skb(sk, skb);
+	if (likely(!rc))
+		return 0;
+
 	if (rc < 0) {
 		int is_udplite = IS_UDPLITE(sk);
 		enum skb_drop_reason drop_reason;
@@ -813,6 +816,9 @@ static int __udpv6_queue_rcv_skb(struct sock *sk,
struct sk_buff *skb)
 		return -1;
 	}

+	/* rc > 0, packets dropped after dequeueing from prod_queue */
+	SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_MEMERRORS, rc);
+	SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_INERRORS, rc);
 	return 0;
 }

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Willem de Bruijn]

Paolo Abeni wrote:
> On 1/23/26 3:41 PM, Willem de Bruijn wrote:
> > Paolo Abeni wrote:
> >> I think that doing the SNMP accounting in __udp_enqueue_schedule_skb()
> >> (for `to_drop`), __udp_queue_rcv_skb() and __udpv6_queue_rcv_skb() (for
> >> `skb`) is a little confusing and possible error prone in the long run.
> >>
> >> I'm wondering if something alike the following (completely untested, not
> >> even built! just to give the idea) would be better?
> > 
> > I don't see the error prone issue with the simpler patch.
> > But SGTM if you prefer this.
> It's not a big deal but if we need to update the UDP MIB someday having
> to look in different places could cause missing something.
> 
> The code I proposed could be made smaller with something alike the
> following (still completely untested), which in turn looks quite alike
> what this patch is heading, I guess. So really it's not a big deal.
> ---
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 1db63db7e5d4..431de8dda0d3 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1793,6 +1795,7 @@ int __udp_enqueue_schedule_skb(struct sock *sk,
> struct sk_buff *skb)
>  		}
>  	}
> 
> +	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
>  	if (unlikely(to_drop)) {
>  		for (nb = 0; to_drop != NULL; nb++) {
>  			skb = to_drop;
> @@ -1802,10 +1805,9 @@ int __udp_enqueue_schedule_skb(struct sock *sk,
> struct sk_buff *skb)
>  			sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
>  		}
>  		numa_drop_add(&udp_sk(sk)->drop_counters, nb);
> +		return nb;
>  	}
> 
> -	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
> -
>  	return 0;
> 
>  drop:
> @@ -2345,6 +2347,9 @@ static int __udp_queue_rcv_skb(struct sock *sk,
> struct sk_buff *skb)
>  	}
> 
>  	rc = __udp_enqueue_schedule_skb(sk, skb);
> +	if (likely(!rc))
> +		return 0;
> +
>  	if (rc < 0) {
>  		int is_udplite = IS_UDPLITE(sk);
>  		int drop_reason;
> @@ -2365,6 +2370,9 @@ static int __udp_queue_rcv_skb(struct sock *sk,
> struct sk_buff *skb)
>  		return -1;
>  	}
> 
> +	/* rc > 0, packets dropped after dequeueing from prod_queue */
> +	SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS, rc);
> +	SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS, rc);
>  	return 0;
>  }
> 
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 010b909275dd..df895096669e 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -793,6 +793,9 @@ static int __udpv6_queue_rcv_skb(struct sock *sk,
> struct sk_buff *skb)
>  	}
> 
>  	rc = __udp_enqueue_schedule_skb(sk, skb);
> +	if (likely(!rc))
> +		return 0;
> +
>  	if (rc < 0) {
>  		int is_udplite = IS_UDPLITE(sk);
>  		enum skb_drop_reason drop_reason;
> @@ -813,6 +816,9 @@ static int __udpv6_queue_rcv_skb(struct sock *sk,
> struct sk_buff *skb)
>  		return -1;
>  	}
> 
> +	/* rc > 0, packets dropped after dequeueing from prod_queue */
> +	SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_MEMERRORS, rc);
> +	SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_INERRORS, rc);
>  	return 0;
>  }
> 

Honestly, I don't see this plumbing of nb as simpler than incrementing
the counters right where nb is known. All it takes there is to make
the second arg to UDPX_MIB conditional on sk_family. But again I don't
care strongly, so SGTM if you do.

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

On Fri, Jan 23, 2026 at 12:56 AM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> Mahdi Faramarzpour wrote:
> > This commit adds SNMP drop count increment for the packets in
> > per NUMA queues which were introduced in commit b650bf0977d3
> > ("udp: remove busylock and add per NUMA queues"). note that SNMP
> > counters are incremented currently by the caller for skb. And
> > that these skbs on the intermediate queue cannot be counted
> > there so need similar logic in their error path.
> >
> > Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
> > ---
> > v5:
> >   - check if drop counts are non-zero before increasing countrers
> > v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
> >   - move all changes to unlikely(to_drop) branch
> > v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
> >   - remove the unreachable UDP_MIB_RCVBUFERRORS code
> > v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
> >   - change ENOMEM to ENOBUFS
> > v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
> > ---
> >  net/ipv4/udp.c | 19 ++++++++++++++++++-
> >  1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > index ffe074cb5..41cf8f7ab 100644
> > --- a/net/ipv4/udp.c
> > +++ b/net/ipv4/udp.c
> > @@ -1793,14 +1793,31 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
> >       }
> >
> >       if (unlikely(to_drop)) {
> > +             int err_ipv4 = 0;
> > +             int err_ipv6 = 0;
>
> nit: whitespace between variable definition and code block
>
> >               for (nb = 0; to_drop != NULL; nb++) {
> >                       skb = to_drop;
> > +                     if (skb->protocol == htons(ETH_P_IP))
> > +                             err_ipv4++;
> > +                     else
> > +                             err_ipv6++;
>
> No need for separate counters.
>
> All counters will either update IPv4 or IPv6 stats. Similar to how
> the caller of _udp_enqueue_schedule_sk is either __udp_queue_rcv_skb
> or __udpv6_queue_rcv_skb and chooses the SNMP stat based on that.
>
> Can check sk_family == PF_INET6 once.
I doubt this. How does this work in case of a dual-stack socket?
>
> >                       to_drop = skb->next;
> >                       skb_mark_not_on_list(skb);
> > -                     /* TODO: update SNMP values. */
> >                       sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
> >               }
> >               numa_drop_add(&udp_sk(sk)->drop_counters, nb);
> > +             if (err_ipv4 > 0) {
> > +                     SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS,
> > +                                    err_ipv4);
> > +                     SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS,
> > +                                    err_ipv4);
> > +             }
> > +             if (err_ipv6 > 0) {
> > +                     SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_MEMERRORS,
> > +                                    err_ipv6);
> > +                     SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_INERRORS,
> > +                                    err_ipv6);
> > +             }
> >       }
> >
> >       atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
> > --
> > 2.34.1
> >
>
>

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Willem de Bruijn]

Mahdi Faramarzpour wrote:
> On Fri, Jan 23, 2026 at 12:56 AM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Mahdi Faramarzpour wrote:
> > > This commit adds SNMP drop count increment for the packets in
> > > per NUMA queues which were introduced in commit b650bf0977d3
> > > ("udp: remove busylock and add per NUMA queues"). note that SNMP
> > > counters are incremented currently by the caller for skb. And
> > > that these skbs on the intermediate queue cannot be counted
> > > there so need similar logic in their error path.
> > >
> > > Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
> > > ---
> > > v5:
> > >   - check if drop counts are non-zero before increasing countrers
> > > v4: https://lore.kernel.org/netdev/20260108102950.49417-1-mahdifrmx@gmail.com/
> > >   - move all changes to unlikely(to_drop) branch
> > > v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
> > >   - remove the unreachable UDP_MIB_RCVBUFERRORS code
> > > v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
> > >   - change ENOMEM to ENOBUFS
> > > v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
> > > ---
> > >  net/ipv4/udp.c | 19 ++++++++++++++++++-
> > >  1 file changed, 18 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > > index ffe074cb5..41cf8f7ab 100644
> > > --- a/net/ipv4/udp.c
> > > +++ b/net/ipv4/udp.c
> > > @@ -1793,14 +1793,31 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
> > >       }
> > >
> > >       if (unlikely(to_drop)) {
> > > +             int err_ipv4 = 0;
> > > +             int err_ipv6 = 0;
> >
> > nit: whitespace between variable definition and code block
> >
> > >               for (nb = 0; to_drop != NULL; nb++) {
> > >                       skb = to_drop;
> > > +                     if (skb->protocol == htons(ETH_P_IP))
> > > +                             err_ipv4++;
> > > +                     else
> > > +                             err_ipv6++;
> >
> > No need for separate counters.
> >
> > All counters will either update IPv4 or IPv6 stats. Similar to how
> > the caller of _udp_enqueue_schedule_sk is either __udp_queue_rcv_skb
> > or __udpv6_queue_rcv_skb and chooses the SNMP stat based on that.
> >
> > Can check sk_family == PF_INET6 once.
> I doubt this. How does this work in case of a dual-stack socket?

I see your point. The question is whether the stats represent socket
family or individual datagrams arriving on that socket. There is
something to be said for the latter.

But given that __udpv6_queue_rcv_skb unconditionally increments UDP6
stats on drop in __udp_enqueue_schedule_skb, the established behavior
seems to be to follow the socket family.

[PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

This commit adds SNMP drop count increment for the packets in
per NUMA queues which were introduced in commit b650bf0977d3
("udp: remove busylock and add per NUMA queues").

Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
---
v4:
  - move all changes to unlikely(to_drop) branch
v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
  - remove the unreachable UDP_MIB_RCVBUFERRORS code
v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
  - change ENOMEM to ENOBUFS
v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
---
 net/ipv4/udp.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index ffe074cb5..399d1a357 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1705,6 +1705,10 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 	unsigned int rmem, rcvbuf;
 	int size, err = -ENOMEM;
 	int total_size = 0;
+	struct {
+		int ipv4;
+		int ipv6;
+	} mem_err_count;
 	int q_size = 0;
 	int dropcount;
 	int nb = 0;
@@ -1793,14 +1797,28 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 	}
 
 	if (unlikely(to_drop)) {
+		mem_err_count.ipv4 = 0;
+		mem_err_count.ipv6 = 0;
 		for (nb = 0; to_drop != NULL; nb++) {
 			skb = to_drop;
+			if (skb->protocol == htons(ETH_P_IP))
+				mem_err_count.ipv4++;
+			else
+				mem_err_count.ipv6++;
 			to_drop = skb->next;
 			skb_mark_not_on_list(skb);
-			/* TODO: update SNMP values. */
 			sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
 		}
 		numa_drop_add(&udp_sk(sk)->drop_counters, nb);
+
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS,
+			       mem_err_count.ipv4);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS,
+			       mem_err_count.ipv4);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_MEMERRORS,
+			       mem_err_count.ipv6);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_INERRORS,
+			       mem_err_count.ipv6);
 	}
 
 	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
-- 
2.34.1

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Willem de Bruijn]

Mahdi Faramarzpour wrote:
> This commit adds SNMP drop count increment for the packets in
> per NUMA queues which were introduced in commit b650bf0977d3
> ("udp: remove busylock and add per NUMA queues").

If respinning anyway, may be worth adding the note that SNMP
counters are incremented currently by the caller for skb. And
that these skbs on the intermediate queue cannot be counted
there so need similar logic in their error path.

> 
> Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
> ---
> v4:
>   - move all changes to unlikely(to_drop) branch
> v3: https://lore.kernel.org/netdev/20260105114732.140719-1-mahdifrmx@gmail.com/
>   - remove the unreachable UDP_MIB_RCVBUFERRORS code
> v2: https://lore.kernel.org/netdev/20260105071218.10785-1-mahdifrmx@gmail.com/
>   - change ENOMEM to ENOBUFS
> v1: https://lore.kernel.org/netdev/20260104105732.427691-1-mahdifrmx@gmail.com/
> ---
>  net/ipv4/udp.c | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index ffe074cb5..399d1a357 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1705,6 +1705,10 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
>  	unsigned int rmem, rcvbuf;
>  	int size, err = -ENOMEM;
>  	int total_size = 0;
> +	struct {
> +		int ipv4;
> +		int ipv6;
> +	} mem_err_count;
>  	int q_size = 0;
>  	int dropcount;
>  	int nb = 0;
> @@ -1793,14 +1797,28 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
>  	}
>  
>  	if (unlikely(to_drop)) {
> +		mem_err_count.ipv4 = 0;
> +		mem_err_count.ipv6 = 0;

Simpler to avoid the struct and in this branch scope define

int err_ipv4 = 0;
int err_ipv6 = 0;

>  		for (nb = 0; to_drop != NULL; nb++) {
>  			skb = to_drop;
> +			if (skb->protocol == htons(ETH_P_IP))
> +				mem_err_count.ipv4++;
> +			else
> +				mem_err_count.ipv6++;
>  			to_drop = skb->next;
>  			skb_mark_not_on_list(skb);
> -			/* TODO: update SNMP values. */
>  			sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
>  		}
>  		numa_drop_add(&udp_sk(sk)->drop_counters, nb);
> +
> +		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS,
> +			       mem_err_count.ipv4);
> +		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS,
> +			       mem_err_count.ipv4);
> +		SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_MEMERRORS,
> +			       mem_err_count.ipv6);
> +		SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_INERRORS,
> +			       mem_err_count.ipv6);

Only add if non-zero.

>  	}
>  
>  	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
> -- 
> 2.34.1
> 

[PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

This commit adds SNMP drop count increment for the packets in
per NUMA queues which were introduced in commit b650bf0977d3
("udp: remove busylock and add per NUMA queues").

Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
---
 net/ipv4/udp.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index ffe074cb5..19ab44e46 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1709,6 +1709,11 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 	int dropcount;
 	int nb = 0;
 
+	struct {
+		int mem4;
+		int mem6;
+	} err_count = { 0, 0 };
+
 	rmem = atomic_read(&sk->sk_rmem_alloc);
 	rcvbuf = READ_ONCE(sk->sk_rcvbuf);
 	size = skb->truesize;
@@ -1760,6 +1765,10 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 		total_size += size;
 		err = udp_rmem_schedule(sk, size);
 		if (unlikely(err)) {
+			if (skb->protocol == htons(ETH_P_IP))
+				err_count.mem4++;
+			else
+				err_count.mem6++;
 			/*  Free the skbs outside of locked section. */
 			skb->next = to_drop;
 			to_drop = skb;
@@ -1797,10 +1806,18 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 			skb = to_drop;
 			to_drop = skb->next;
 			skb_mark_not_on_list(skb);
-			/* TODO: update SNMP values. */
 			sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
 		}
 		numa_drop_add(&udp_sk(sk)->drop_counters, nb);
+
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS,
+			       err_count.mem4);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS,
+			       err_count.mem4);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_MEMERRORS,
+			       err_count.mem6);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_INERRORS,
+			       err_count.mem6);
 	}
 
 	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
-- 
2.34.1

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Jakub Kicinski]

On Mon,  5 Jan 2026 15:17:32 +0330 Mahdi Faramarzpour wrote:
> This commit adds SNMP drop count increment for the packets in
> per NUMA queues which were introduced in commit b650bf0977d3
> ("udp: remove busylock and add per NUMA queues").

You must not submit more than one version of a patch within a 24h
period.

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

On Tue, Jan 6, 2026 at 5:24 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon,  5 Jan 2026 15:17:32 +0330 Mahdi Faramarzpour wrote:
> > This commit adds SNMP drop count increment for the packets in
> > per NUMA queues which were introduced in commit b650bf0977d3
> > ("udp: remove busylock and add per NUMA queues").
>
> You must not submit more than one version of a patch within a 24h
> period.
Hi Jakub and sorry for the noise, didn't know that. Is there any way to check
my patch against all patchwork checks ,specially the AI-reviewer
before submitting it?

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Willem de Bruijn]

Mahdi Faramarzpour wrote:
> On Tue, Jan 6, 2026 at 5:24 AM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Mon,  5 Jan 2026 15:17:32 +0330 Mahdi Faramarzpour wrote:
> > > This commit adds SNMP drop count increment for the packets in
> > > per NUMA queues which were introduced in commit b650bf0977d3
> > > ("udp: remove busylock and add per NUMA queues").

Can you give some rationale why the existing counters are insufficient
and why you chose to change then number of counters you suggest
between revisions of your patch?

This code adds some cost to the hot path. The blamed commit added
drop counters, most likely weighing the value of counters against
their cost. I don't immediately see reason to revisit that.

> >
> > You must not submit more than one version of a patch within a 24h
> > period.
> Hi Jakub and sorry for the noise, didn't know that. Is there any way to check
> my patch against all patchwork checks ,specially the AI-reviewer
> before submitting it?

See https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

On Tue, Jan 6, 2026 at 10:52 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> Mahdi Faramarzpour wrote:
> > On Tue, Jan 6, 2026 at 5:24 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > >
> > > On Mon,  5 Jan 2026 15:17:32 +0330 Mahdi Faramarzpour wrote:
> > > > This commit adds SNMP drop count increment for the packets in
> > > > per NUMA queues which were introduced in commit b650bf0977d3
> > > > ("udp: remove busylock and add per NUMA queues").
>
> Can you give some rationale why the existing counters are insufficient
> and why you chose to change then number of counters you suggest
> between revisions of your patch?
>
The difference between revisions is due to me realizing that the only error the
udp_rmem_schedule returns is ENOBUFS, which is mapped to UDP_MIB_MEMERRORS
(refer to function __udp_queue_rcv_skb), and thus UDP_MIB_RCVBUFERRORS
need not increase.

> This code adds some cost to the hot path. The blamed commit added
> drop counters, most likely weighing the value of counters against
> their cost. I don't immediately see reason to revisit that.
>
AFAIU the drop_counter is per socket, while the counters added in this
patch correspond
to /proc/net/{snmp,snmp6} pseudofiles. This patch implements the todo
comment added in
the blamed commit.

> > >
> > > You must not submit more than one version of a patch within a 24h
> > > period.
> > Hi Jakub and sorry for the noise, didn't know that. Is there any way to check
> > my patch against all patchwork checks ,specially the AI-reviewer
> > before submitting it?
>
> See https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>
thanks.

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Willem de Bruijn]

Mahdi Faramarzpour wrote:
> On Tue, Jan 6, 2026 at 10:52 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Mahdi Faramarzpour wrote:
> > > On Tue, Jan 6, 2026 at 5:24 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > > >
> > > > On Mon,  5 Jan 2026 15:17:32 +0330 Mahdi Faramarzpour wrote:
> > > > > This commit adds SNMP drop count increment for the packets in
> > > > > per NUMA queues which were introduced in commit b650bf0977d3
> > > > > ("udp: remove busylock and add per NUMA queues").
> >
> > Can you give some rationale why the existing counters are insufficient
> > and why you chose to change then number of counters you suggest
> > between revisions of your patch?
> >
> The difference between revisions is due to me realizing that the only error the
> udp_rmem_schedule returns is ENOBUFS, which is mapped to UDP_MIB_MEMERRORS
> (refer to function __udp_queue_rcv_skb), and thus UDP_MIB_RCVBUFERRORS
> need not increase.

I see. Please make such a note in the revision changelog. See also

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#changes-requested

> > This code adds some cost to the hot path. The blamed commit added
> > drop counters, most likely weighing the value of counters against
> > their cost. I don't immediately see reason to revisit that.
> >
> AFAIU the drop_counter is per socket, while the counters added in this
> patch correspond
> to /proc/net/{snmp,snmp6} pseudofiles. This patch implements the todo
> comment added in
> the blamed commit.

Ah indeed.

The entire logic can be inside the unlikely(to_drop) branch right?
No need to initialize the counters in the hot path, or do the
skb->protocol earlier?

The previous busylock approach could also drop packets at this stage
(goto uncharge_drop), and the skb is also dropped if exceeding rcvbuf.
Neither of those conditions update SNMP stats. I'd like to understand
what makes this case different.

> > > >
> > > > You must not submit more than one version of a patch within a 24h
> > > > period.
> > > Hi Jakub and sorry for the noise, didn't know that. Is there any way to check
> > > my patch against all patchwork checks ,specially the AI-reviewer
> > > before submitting it?
> >
> > See https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
> >
> thanks.

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

On Wed, Jan 7, 2026 at 6:39 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> Mahdi Faramarzpour wrote:
> > On Tue, Jan 6, 2026 at 10:52 PM Willem de Bruijn
> > <willemdebruijn.kernel@gmail.com> wrote:
> > >
> > > Mahdi Faramarzpour wrote:
> > > > On Tue, Jan 6, 2026 at 5:24 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > > > >
> > > > > On Mon,  5 Jan 2026 15:17:32 +0330 Mahdi Faramarzpour wrote:
> > > > > > This commit adds SNMP drop count increment for the packets in
> > > > > > per NUMA queues which were introduced in commit b650bf0977d3
> > > > > > ("udp: remove busylock and add per NUMA queues").
> > >
> > > Can you give some rationale why the existing counters are insufficient
> > > and why you chose to change then number of counters you suggest
> > > between revisions of your patch?
> > >
> > The difference between revisions is due to me realizing that the only error the
> > udp_rmem_schedule returns is ENOBUFS, which is mapped to UDP_MIB_MEMERRORS
> > (refer to function __udp_queue_rcv_skb), and thus UDP_MIB_RCVBUFERRORS
> > need not increase.
>
> I see. Please make such a note in the revision changelog. See also
>
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#changes-requested
>
Ok.

> > > This code adds some cost to the hot path. The blamed commit added
> > > drop counters, most likely weighing the value of counters against
> > > their cost. I don't immediately see reason to revisit that.
> > >
> > AFAIU the drop_counter is per socket, while the counters added in this
> > patch correspond
> > to /proc/net/{snmp,snmp6} pseudofiles. This patch implements the todo
> > comment added in
> > the blamed commit.
>
> Ah indeed.
>
> The entire logic can be inside the unlikely(to_drop) branch right?
> No need to initialize the counters in the hot path, or do the
> skb->protocol earlier?
>
Right.

> The previous busylock approach could also drop packets at this stage
> (goto uncharge_drop), and the skb is also dropped if exceeding rcvbuf.
> Neither of those conditions update SNMP stats. I'd like to understand
> what makes this case different.
>
The difference comes from the intermediate udp_prod_queue which contains
packets from calls to __udp_enqueue_schedule_skb that reached this branch:

    if (!llist_add(&skb->ll_node, &udp_prod_queue->ll_root))
        return 0;

these packets might be dropped in batch later by the call that reaches the
unlikely(to_drop) branch, and thus SNMP stats must increase. Note that such
packets are only dropped due to the ENOBUFS returned from udp_rmem_schedule.

> > > > >
> > > > > You must not submit more than one version of a patch within a 24h
> > > > > period.
> > > > Hi Jakub and sorry for the noise, didn't know that. Is there any way to check
> > > > my patch against all patchwork checks ,specially the AI-reviewer
> > > > before submitting it?
> > >
> > > See https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
> > >
> > thanks.
>
>

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Willem de Bruijn]

Mahdi Faramarzpour wrote:
> On Wed, Jan 7, 2026 at 6:39 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Mahdi Faramarzpour wrote:
> > > On Tue, Jan 6, 2026 at 10:52 PM Willem de Bruijn
> > > <willemdebruijn.kernel@gmail.com> wrote:
> > > >
> > > > Mahdi Faramarzpour wrote:
> > > > > On Tue, Jan 6, 2026 at 5:24 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > > > > >
> > > > > > On Mon,  5 Jan 2026 15:17:32 +0330 Mahdi Faramarzpour wrote:
> > > > > > > This commit adds SNMP drop count increment for the packets in
> > > > > > > per NUMA queues which were introduced in commit b650bf0977d3
> > > > > > > ("udp: remove busylock and add per NUMA queues").
> > > >
> > > > Can you give some rationale why the existing counters are insufficient
> > > > and why you chose to change then number of counters you suggest
> > > > between revisions of your patch?
> > > >
> > > The difference between revisions is due to me realizing that the only error the
> > > udp_rmem_schedule returns is ENOBUFS, which is mapped to UDP_MIB_MEMERRORS
> > > (refer to function __udp_queue_rcv_skb), and thus UDP_MIB_RCVBUFERRORS
> > > need not increase.
> >
> > I see. Please make such a note in the revision changelog. See also
> >
> > https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#changes-requested
> >
> Ok.
> 
> > > > This code adds some cost to the hot path. The blamed commit added
> > > > drop counters, most likely weighing the value of counters against
> > > > their cost. I don't immediately see reason to revisit that.
> > > >
> > > AFAIU the drop_counter is per socket, while the counters added in this
> > > patch correspond
> > > to /proc/net/{snmp,snmp6} pseudofiles. This patch implements the todo
> > > comment added in
> > > the blamed commit.
> >
> > Ah indeed.
> >
> > The entire logic can be inside the unlikely(to_drop) branch right?
> > No need to initialize the counters in the hot path, or do the
> > skb->protocol earlier?
> >
> Right.
> 
> > The previous busylock approach could also drop packets at this stage
> > (goto uncharge_drop), and the skb is also dropped if exceeding rcvbuf.
> > Neither of those conditions update SNMP stats. I'd like to understand
> > what makes this case different.
> >
> The difference comes from the intermediate udp_prod_queue which contains
> packets from calls to __udp_enqueue_schedule_skb that reached this branch:
> 
>     if (!llist_add(&skb->ll_node, &udp_prod_queue->ll_root))
>         return 0;
> 
> these packets might be dropped in batch later by the call that reaches the
> unlikely(to_drop) branch, and thus SNMP stats must increase. Note that such
> packets are only dropped due to the ENOBUFS returned from udp_rmem_schedule.

Understood.

The difference with the other drops is that those are on the skb that
is being passed to __udp_enqueue_schedule_skb, and are accounted to
the SNMP stats in the caller when __udp_enqueue_schedule_skb returns
with an error.

The skbs queued here cannot be accounted that way, so require
additional separate SNMP adds.

> > > > > >
> > > > > > You must not submit more than one version of a patch within a 24h
> > > > > > period.
> > > > > Hi Jakub and sorry for the noise, didn't know that. Is there any way to check
> > > > > my patch against all patchwork checks ,specially the AI-reviewer
> > > > > before submitting it?
> > > >
> > > > See https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
> > > >
> > > thanks.
> >
> >

Re: [PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Jakub Kicinski]

On Tue, 6 Jan 2026 09:41:04 +0330 Mahdi Faramarzpour wrote:
> > You must not submit more than one version of a patch within a 24h
> > period.  
> Hi Jakub and sorry for the noise, didn't know that. Is there any way to check
> my patch against all patchwork checks ,specially the AI-reviewer
> before submitting it?

Unfortunately we don't have sufficient funds to open up the access to
AI reviews. But we are just using the public review prompts from Chris
Mason https://lwn.net/Articles/1041694/ so if you have Gemini / Claude
etc. access you can run them "locally".

[PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

This commit adds SNMP drop count increment for the packets in
per NUMA queues which were introduced in commit b650bf0977d3
("udp: remove busylock and add per NUMA queues").

Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
---
 net/ipv4/udp.c | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index ffe074cb5..9dbbe4da9 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1709,6 +1709,13 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 	int dropcount;
 	int nb = 0;
 
+	struct {
+		int rcvbuf4;
+		int rcvbuf6;
+		int mem4;
+		int mem6;
+	} err_count = {0, 0, 0, 0};
+
 	rmem = atomic_read(&sk->sk_rmem_alloc);
 	rcvbuf = READ_ONCE(sk->sk_rcvbuf);
 	size = skb->truesize;
@@ -1760,6 +1767,17 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 		total_size += size;
 		err = udp_rmem_schedule(sk, size);
 		if (unlikely(err)) {
+			if (err == -ENOBUFS) {
+				if (skb->protocol == htons(ETH_P_IP))
+					err_count.rcvbuf4++;
+				else
+					err_count.rcvbuf6++;
+			} else {
+				if (skb->protocol == htons(ETH_P_IP))
+					err_count.mem4++;
+				else
+					err_count.mem6++;
+			}
 			/*  Free the skbs outside of locked section. */
 			skb->next = to_drop;
 			to_drop = skb;
@@ -1797,10 +1815,22 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 			skb = to_drop;
 			to_drop = skb->next;
 			skb_mark_not_on_list(skb);
-			/* TODO: update SNMP values. */
 			sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
 		}
 		numa_drop_add(&udp_sk(sk)->drop_counters, nb);
+
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_RCVBUFERRORS,
+			       err_count.rcvbuf4);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS,
+			       err_count.mem4);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS,
+			       err_count.mem4 + err_count.rcvbuf4);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_RCVBUFERRORS,
+			       err_count.rcvbuf6);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_MEMERRORS,
+			       err_count.mem6);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_INERRORS,
+			       err_count.mem6 + err_count.rcvbuf6);
 	}
 
 	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
-- 
2.34.1

[PATCH net-next] udp: add drop count for packets in udp_prod_queue

[Mahdi Faramarzpour]

This commit adds SNMP drop count increment for the packets in
per NUMA queues which were introduced in commit b650bf0977d3
("udp: remove busylock and add per NUMA queues").

Signed-off-by: Mahdi Faramarzpour <mahdifrmx@gmail.com>
---
 net/ipv4/udp.c | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index ffe074cb5..aff8cab57 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1709,6 +1709,13 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 	int dropcount;
 	int nb = 0;
 
+	struct {
+		int rcvbuf4;
+		int rcvbuf6;
+		int mem4;
+		int mem6;
+	} err_count = {0, 0, 0, 0};
+
 	rmem = atomic_read(&sk->sk_rmem_alloc);
 	rcvbuf = READ_ONCE(sk->sk_rcvbuf);
 	size = skb->truesize;
@@ -1760,6 +1767,17 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 		total_size += size;
 		err = udp_rmem_schedule(sk, size);
 		if (unlikely(err)) {
+			if (err == -ENOMEM) {
+				if (skb->protocol == htons(ETH_P_IP))
+					err_count.rcvbuf4++;
+				else
+					err_count.rcvbuf6++;
+			} else {
+				if (skb->protocol == htons(ETH_P_IP))
+					err_count.mem4++;
+				else
+					err_count.mem6++;
+			}
 			/*  Free the skbs outside of locked section. */
 			skb->next = to_drop;
 			to_drop = skb;
@@ -1797,10 +1815,22 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb)
 			skb = to_drop;
 			to_drop = skb->next;
 			skb_mark_not_on_list(skb);
-			/* TODO: update SNMP values. */
 			sk_skb_reason_drop(sk, skb, SKB_DROP_REASON_PROTO_MEM);
 		}
 		numa_drop_add(&udp_sk(sk)->drop_counters, nb);
+
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_RCVBUFERRORS,
+			       err_count.rcvbuf4);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_MEMERRORS,
+			       err_count.mem4);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, true), UDP_MIB_INERRORS,
+			       err_count.mem4 + err_count.rcvbuf4);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_RCVBUFERRORS,
+			       err_count.rcvbuf6);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_MEMERRORS,
+			       err_count.mem6);
+		SNMP_ADD_STATS(__UDPX_MIB(sk, false), UDP_MIB_INERRORS,
+			       err_count.mem6 + err_count.rcvbuf6);
 	}
 
 	atomic_sub(total_size, &udp_prod_queue->rmem_alloc);
-- 
2.34.1