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

[Michael Clark <michael@metaparadigm.com>]

On 10/21/04 06:00, H. Peter Anvin wrote:
> Chris Friesen wrote:
> 
>> H. Peter Anvin wrote:
>>
>>> EIO seems to be The Right Thing[TM]... it pretty much says "yes, we
>>> received something, but it was bad."  What isn't clear to me is how
>>> applications react to EIO.  It could easily be considered a fatal
>>> error... :-/
>>
>>
>>
>>  From an application point of view, The Right Thing would be to do the 
>> checksum validation at select() time if the socket is blocking.
>>
>> If it's nonblocking, then just do as we do now and return EAGAIN at 
>> recvmsg() time.
>>
>> This would ensure that all existing apps get the expected semantics, 
>> but the ones based on blocking sockets would see a performance 
>> degredation.
>>
> 
> Doing work twice can hardly be considered The Right Thing.

Optimisations that break documented interfaces and age old assumptions
can hardly be considered The Right Thing :)

And you only do the checksum once (just earlier), and the copy_to_user
should be cache hot as most of these UDP apps will call recvmesg right
after the select.

That said, an app with many connected sockets will have a high chance
of losing the cache. Although a handful of unconnected UDP sockets
(one per interface) are more common in the use case of a large number
of clients, so in general the performance difference should be minor.

Doing the same amount work (with chance of lower performance because of
cache loss) is good IMHO if it means the choice of a reliable vs an
unreliable interface. You can only take the performance optimisation
argument so far and when these optimisations start breaking interfaces,
i think that's too far ie. what to give up efficiency vs. correctness?

Just my 2c in favour of !O_NONBLOCK early UDP checksum test in select.

~mc