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

Ilkka Ollakka ileoo at videolan.org
Wed Oct 17 23:11:50 CEST 2018

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20181018/bdc18ffc/attachment.sig>

More information about the vlc-devel mailing list