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 coul
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 @@
|
|Th
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 http://w
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
> UdpIn
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 EarlyDatag
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?
>
[SN
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:
> http://www.m
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
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
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
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 c
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 o
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 o
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
> > > > >
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
> > >
> > > 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
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
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
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
>
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
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
inet_diag interface for UDP and put the number of queued packets
for ea
David Miller said the following on 2007-11-19 6:40:
> 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
> I
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 re
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
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(
> 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 t
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,
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.
>>
> "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
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. Ch
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 no
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 ne
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.
>
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
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 c
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
> avail
36 matches
Mail list logo
