On Sun, 19 Jun 2011 12:44:03 +0300 Kostik Belousov wrote:
KB> On Wed, Jun 15, 2011 at 09:44:33AM +0300, Mikolaj Golub wrote:
>>
>> On Tue, 14 Jun 2011 12:23:03 +0300 Kostik Belousov wrote:
>>
>> KB> I do not understand what then happens for the recvfrom(2) call ?
>> KB> Would it get some error, or 0 as return and no data, or something else
>> ?
>>
>> It will wait for data below in another loop ("Now continue to read any data
>> mbufs off of the head...").
>>
>> Elaborating, I would split soreceive_generic on three logical parts.
>>
>> In the first (restart) part we block until some data are received and also
>> (without the patch) in the case of MSG_WAITALL if the buffer is big enough
>> we
>> block until all MSG_WAITALL request is received (actually it will spin in
>> "goto restart" loop until some condition becomes invalid).
>>
>> The second part is some processing of received data and the third part is a
>> "while" loop where data is copied to userspace and in the case of
>> MSG_WAITALL
>> request if not all data is received to satisfy the request it also waits for
>> this data.
>>
>> My patch removes the condition in the first part in the case of MSG_WAITALL
>> to
>> wait for all data if buffer is big enough. We always will wait for the rest
>> of
>> data in the third part. It might be not so effective, and this is my first
>> concern about the patch (although not big :-).
KB> Now I think that this part of the patch is right.
KB> The loop in the soreceive_generic() would behave as I would expect
KB> it for MSG_WAITALL. It copyout the received data to userspace by
KB> received chunks.
KB> I do not understand your note about effectiveness there.
The old behaviour: if only a part of the request is recived and the buffer is
large enough, wait for the rest and then go to processing.
The new behaviour: if a part of data is recived, (unconditionally) process it
and wait for the rest (and process).
The first one looks a little more efficient (but has the issue for edge case
with nearly full buffer).
--
Mikolaj Golub
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
