Re: UDP recvmsg blocks after select(), 2.6 bug?

[linux]

> There is one claim I'd like to question - the claim that select()
> would be slowed down unnecessarily, even if the behaviour was changed
> for both O_NONBLOCK enabled. Isn't it more expensive to allow the
> application to be woken up, and poll using read(), than to just do a
> quick check in the kernel and not tell the application there is data,
> when there really isn't?

It depends on how often the second check fails.

The 99.9+% case is that the checksum is good, and in that case, you have
to pay the wakeup cost anyway.  (So sending bad-checksum packets isn't
even a useful DoS; good-checksum packets still steal more cycles.)

You only get the benefit of saving the wakeup if the check fails.
But every time it passes, you get the benefit of making the check cheaper.
You have to multiply by the relative probabilities to see the net effect.

For something like UDP checksums on packets which have already passed the
ethernet checksum, that's a pretty overwhelming ratio.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/