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 packets, and expect the > > InDatagrams counter to increase once the stack eats the packet. > > Who expects that? Is there really any program who relies on that? > > If it's just a human: there are a couple of "non intuitive" behaviours > in the stack. This would be just another one. Not too big a deal. I would consider this a legitimate thing to check in a test suite such as TAHI or similar. 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. The behavior would suck. > > But it won't until the application does the read. > > > > 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 worse than a single missing packet. So you would replace > one error with a worse error. This can be fixed, the above cannot. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
