[vlc-devel] [PATCH] access/udp: reduce mtu amount on initial packets

[Rémi Denis-Courmont]

Of course varying sizes happen.

And we cannot wreck the performance of sane usage (1500 bytes or less) just to support insane usage. Allocating 64 KiB block probably requires between 68 and 128 KiB of heap depending on implementation; it is *not* suitable for receiving 1500 bytes packets.

Le 18 octobre 2018 00:11:50 GMT+03:00, Ilkka Ollakka <ileoo at videolan.org> a écrit :
>On Wed, Oct 17, 2018 at 07:05:25PM +0300, Rémi Denis-Courmont wrote:
>> Le tiistaina 16. lokakuuta 2018, 21.16.19 EEST Ilkka Ollakka a écrit
>:
>> > In this approach, mtu is setted to high on start, and if received
>data
>> > is less than 1500 and mtu is higher than that, we adjust mtu on
>future
>> > packets to be smaller. In majority of cases in UDP streaming,
>packet
>> > size is usually quite constant, so it should work, even if it's not
>> > generic solution to udp packet receiving.
>
>> I don't think we can shrink the receive buffer on the basis of a
>single 
>> packet, or really any number of packets.
>
>In theory it's possible that packet sizes vary hugely. But in practise,
>what I have seen, they are most likely below 1500 or way above 1500. Or
>have you seen different style of streams in plain udp streams?
>
>If we don't leave the assumption aside that vlc udp access should be
>able to handle all kind of udp traffic, then the approach and
>performance penalties needs to be taken, but if we can make assumption
>that vlc udp access is intended for media receiving, then why couldn't
>we assume things on stream?
>
>And anyway if it gets truncated, there is a code to increase the size
>later on.
>
>Ofcourse you can take the approach to do the MSG_PEEK to get perfect
>size for every receive, but most likely that would have already been
>taken if there weren't cost for that approach as well?
>
>Or you can take huge buffer just in case, and pass that around. But
>that
>approach had it's own issues.
>
>Or, like you said, big buffer and memcpy needed parts. But thats also
>hasn't happened and doesn't really help on performance side.
>
>I know the proposed approach is not perfect, but I haven't yet hear any
>real world examples why it wouldn't work.
>
>If people don't like the approach, it's ok to say it like that, no need
>to try make up corner cases that aren't really happening or other
>excuses. Just plain 'I don't like it' and we can all focus the time to
>something else.
>
>-- 
>Ilkka Ollakka
>The best you get is an even break.
>		-- Franklin Adams

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20181018/965f01d7/attachment.html>