On Thu, Nov 29, 2007 at 03:55:38PM +0800, Wang Chen wrote:
I tested nfsv3 nfsv4. It seems that nfs calls recvmsg() like
following:nfsd()-svc_recv()-svc_udp_recvfrom()-udp_recvmsg().
So, I think putting the udpInDatagrams increment in udp_recvmsg()
is enough.
FYI:
On Thu, Nov 29, 2007 at 06:08:30PM +0800, Wang Chen wrote:
Add a new UdpInEarlyDatagrams counter to count datagrams received early,
but which might be dropped later.
Could you please split this into two patches? Have one do the
UdpInDatagrams change and the other to introduce the
Herbert Xu said the following on 2007-11-29 18:21:
On Thu, Nov 29, 2007 at 06:08:30PM +0800, Wang Chen wrote:
Add a new UdpInEarlyDatagrams counter to count datagrams received early,
but which might be dropped later.
Could you please split this into two patches? Have one do the
Herbert Xu said the following on 2007-11-29 17:21:
On Thu, Nov 29, 2007 at 03:55:38PM +0800, Wang Chen wrote:
Excellent. They now do a recvmsg first with no buffer to get
meta-information, which just happens to increment the counters.
Could you please resubmit the patch then?
[SNMP]:
On Thu, Nov 29, 2007 at 06:33:01PM +0800, Wang Chen wrote:
I cooked the patch based on Andi's and left the new counter.
Frankly, I don't like the EarlyDatagrams too.
So, I will remove it and resubmit.
Sounds good. Thanks for all your efforts on this problem!
--
Visit Openswan at
Thank you for doing this work, there is a small comment below.
| --- linux-2.6.24.rc3.org/Documentation/networking/udplite.txt 2007-11-19
12:37:40.0 +0800
| +++ linux-2.6.24.rc3/Documentation/networking/udplite.txt 2007-11-28
18:35:29.0 +0800
| @@ -236,7 +236,7 @@
|
|
On Thu, Nov 29, 2007 at 10:56:48AM +, Gerrit Renker wrote:
| - InDatagrams: Total number of received datagrams.
| + InDatagrams: The total number of UDP datagrams delivered to UDP
users.
You are in the UDP-Lite documentation -- it should read UDP-Lite, not UDP.
We could just
David Miller said the following on 2007-11-21 9:39:
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 15:05:18 +0100
On Tue, Nov 20, 2007 at 12:29:45AM -0500, Bill Fink wrote:
While I agree with your analysis that it could be worked around,
who knows how all the various SNMP
On Tue, Nov 20, 2007 at 12:29:45AM -0500, Bill Fink wrote:
While I agree with your analysis that it could be worked around,
who knows how all the various SNMP monitoring applications out there
would interpret such an unusual event. I liked Stephen's suggestion
of a deferred decrement that
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 15:05:18 +0100
On Tue, Nov 20, 2007 at 12:29:45AM -0500, Bill Fink wrote:
While I agree with your analysis that it could be worked around,
who knows how all the various SNMP monitoring applications out there
would interpret such an
From: Herbert Xu [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 09:09:29 +0800
In any case, I just looked up RFC1213 and it says:
udpInDatagrams OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
From: Wang Chen [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 10:02:03 +0800
So if udp_queue_rcv_skb() doing sucessfully means a UDP
datagrams delivered to UDP users, the InDatagrams should be
increased in udp_queue_rcv_skb().
Otherwise it should be increased until the UDP datagrams is
actually
From: Herbert Xu [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 12:41:17 +0800
On Sun, Nov 18, 2007 at 02:40:10PM -0800, David Miller wrote:
This can be fixed, the above cannot.
That's a good point. Perhaps one way of getting that info to
the user without putting it in UDPInDatagrams is to
Em Mon, Nov 19, 2007 at 12:41:17PM +0800, Herbert Xu escreveu:
On Sun, Nov 18, 2007 at 02:40:10PM -0800, David Miller wrote:
This can be fixed, the above cannot.
That's a good point. Perhaps one way of getting that info to
the user without putting it in UDPInDatagrams is to create an
All of our options suck, we just have to choose the least sucking one
and right now to me that's decrementing the counter as much as I
empathize with the SNMP application overflow detection issue.
If the SNMP monitor detects an false overflow the error it reports
will be much
From: Andi Kleen [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 16:29:33 +0100
All of our options suck, we just have to choose the least sucking one
and right now to me that's decrementing the counter as much as I
empathize with the SNMP application overflow detection issue.
If
On Mon, 19 Nov 2007, David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 16:29:33 +0100
All of our options suck, we just have to choose the least sucking one
and right now to me that's decrementing the counter as much as I
empathize with the SNMP
David Miller said the following on 2007-11-20 14:15:
From: Bill Fink [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 00:29:45 -0500
But the best approach seems to be just not to count
it in the first place until tha application has actually received
the packet, since as Herbert pointed out, that's
On Tue, Nov 20, 2007 at 02:25:23PM +0800, Wang Chen wrote:
I want to wait for more suggestions until make such patch.
Because this solution leads to troubles with some apps, such as NFS.
(http://bugzilla.kernel.org/show_bug.cgi?id=6660#c2)
Well that's easy. Just get NFS to increment the
From: Bill Fink [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 00:29:45 -0500
But the best approach seems to be just not to count
it in the first place until tha application has actually received
the packet, since as Herbert pointed out, that's what the RFC
actually specifies for the meaning of the
We could defer the increment until we check the checksum,
but that is likely to break even more things because people
(as Wang Chen did initially) will send a packet to some
port with an app that doesn't eat the packets, and expect the
InDatagrams counter to increase once the stack eats the
David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: Sat, 17 Nov 2007 14:18:46 +0100
Wang Chen [EMAIL PROTECTED] writes:
Herbert Xu said the following on 2007-11-16 12:11:
Wang Chen [EMAIL PROTECTED] wrote:
So, I think the checksum in udp_queue_rcv_skb()
From: Andi Kleen [EMAIL PROTECTED]
Date: Sun, 18 Nov 2007 22:45:15 +0100
We could defer the increment until we check the checksum,
but that is likely to break even more things because people
(as Wang Chen did initially) will send a packet to some
port with an app that doesn't eat the
On Sun, Nov 18, 2007 at 02:40:10PM -0800, David Miller wrote:
The networking stack DID receive the packet. Just because a socket
owner is busy doing something else or blocked on some other event
is no excuse not to bump the InDataGgrams counter.
Actually if we ever implement the memory
Wang Chen [EMAIL PROTECTED] writes:
Herbert Xu said the following on 2007-11-16 12:11:
Wang Chen [EMAIL PROTECTED] wrote:
So, I think the checksum in udp_queue_rcv_skb() actually does
the work, not that in udp_recvmsg() and udp_poll().
If I am wrong, please point out.
We may have a bug
From: Andi Kleen [EMAIL PROTECTED]
Date: Sat, 17 Nov 2007 14:18:46 +0100
Wang Chen [EMAIL PROTECTED] writes:
Herbert Xu said the following on 2007-11-16 12:11:
Wang Chen [EMAIL PROTECTED] wrote:
So, I think the checksum in udp_queue_rcv_skb() actually does
the work, not that in
DM == David Miller [EMAIL PROTECTED] writes:
DM When the user does a recvmsg() or a poll() on the socket, we will
DM notice the bad checksum then and increment InErrors. We could in
DM this case correct the InDatagrams counter by decrementing it in
DM this case.
Does that mean that InDatagrams
Dave,
The current kernel doesn't verify the udp checksum if user doesn't set a
socket filter.It's fine for LAN. But for WAN, it's not a good option.
Shall we fix it? Below is the patch to make udp checksum be always
available.
[IPV4] UDP: Always checksum even if without socket filter
Make udp
From: Wang Chen [EMAIL PROTECTED]
Date: Fri, 16 Nov 2007 10:46:26 +0800
The current kernel doesn't verify the udp checksum if user doesn't set a
socket filter.It's fine for LAN. But for WAN, it's not a good option.
Shall we fix it? Below is the patch to make udp checksum be always
available.
David Miller said the following on 2007-11-16 10:54:
From: Wang Chen [EMAIL PROTECTED]
Date: Fri, 16 Nov 2007 10:46:26 +0800
The current kernel doesn't verify the udp checksum if user doesn't set a
socket filter.It's fine for LAN. But for WAN, it's not a good option.
Shall we fix it? Below
From: Wang Chen [EMAIL PROTECTED]
Date: Fri, 16 Nov 2007 11:18:16 +0800
Actually, I tested and found this issue.
I sent 50 udp packets, which have wrong checksum, to my
machine.
Before the patch being applied, /proc/net/snmp's udp
InDatagrams increased, and InErrors didn't increase.
After
Wang Chen [EMAIL PROTECTED] wrote:
So, I think the checksum in udp_queue_rcv_skb() actually does
the work, not that in udp_recvmsg() and udp_poll().
If I am wrong, please point out.
We may have a bug in the accounting area. Check the recent
patch made to UDP/IPv6 which is probably needed
David Miller said the following on 2007-11-16 12:04:
From: Wang Chen [EMAIL PROTECTED]
Date: Fri, 16 Nov 2007 11:18:16 +0800
That's right, InDataGrams will increase even if we haven't
verified the checksum yet.
When the user does a recvmsg() or a poll() on the socket,
we will notice the
Herbert Xu said the following on 2007-11-16 12:11:
Wang Chen [EMAIL PROTECTED] wrote:
So, I think the checksum in udp_queue_rcv_skb() actually does
the work, not that in udp_recvmsg() and udp_poll().
If I am wrong, please point out.
We may have a bug in the accounting area. Check the
34 matches
Mail list logo
