[RFC] UDP SndbufErrors interface and the /proc/net/udp interface.

[RFC] UDP SndbufErrors interface and the /proc/net/udp interface.

[Ian Brown]

Hello,

You can see UDP RcvbufErrors via /proc/net/snmp interface.
These are UDP RcvbufErrors per system.

A recent patch (from two weeks ago) added the ability to view
RcvbufErrors also per
port, via /proc/net/udp. This was done by incrementing sk_drops of the
sock struct when RcvbufErrors is incremented; see , in udp.c (both in
ipv4 and in ipv6)
the call to atomic_inc(&sk->sk_drops).

see:
http://kerneltrap.org/mailarchive/linux-netdev/2008/6/17/2153994

You can see UDP SndbufErrors also via /proc/net/snmp interface.
These are UDP SndbufErrors per system.
I was wondering if it is worthwhile to enable viewing SndbufErrors per
port, via /proc/net/udp interface. It could be done, for example, by adding
a member to the sock structure, for example, sk_send_err, (or
sk_udp_send_drop) incrementing it when SndbufErrors
is incremented, and adding code enable viewing it via /proc/net/udp interface.

I wonder: would such a patch (form me or others) in needed ? Or will
it be rejected because this idea is not good ?
In case this idea is not good, I wonder what is the reason for it.

Regards,
Ian

Re: [RFC] UDP SndbufErrors interface and the /proc/net/udp interface.

[Andi Kleen]

"Ian Brown" <ianbrn@gmail.com> writes:
>
> I wonder: would such a patch (form me or others) in needed ? Or will
> it be rejected because this idea is not good ?
> In case this idea is not good, I wonder what is the reason for it.

One possible reason against it is that struct sock size is relatively 
critical for memory consumption and there's usually some resistance
against adding more fields for it.

That might be overriden by a very clear use case.

-Andi

Re: [RFC] UDP SndbufErrors interface and the /proc/net/udp interface.

[Ian Brown]

Hello,
>That might be overriden by a very clear use case.


What I had in mind is this:

This can help in debugging problems.

I have a machine which works with many UDP sockets. After some hours
(sometimes days), there are problems ; some of them might be due to
that UDP packets are not sent. I want to know stats per UDP port so
that I will know for each socket how many packets were not sent; in
current implementation, I can only know the total of these packets,
and not per port (by probing into the /proc/net/snmp stats)

Regards,
Ian


On Tue, Jul 1, 2008 at 1:18 PM, Andi Kleen <andi@firstfloor.org> wrote:
> "Ian Brown" <ianbrn@gmail.com> writes:
>>
>> I wonder: would such a patch (form me or others) in needed ? Or will
>> it be rejected because this idea is not good ?
>> In case this idea is not good, I wonder what is the reason for it.
>
> One possible reason against it is that struct sock size is relatively
> critical for memory consumption and there's usually some resistance
> against adding more fields for it.
>
> That might be overriden by a very clear use case.
>
> -Andi
>
>