[Bug 772841] udpsrc: high CPU usage at high packet rate

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=772841

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #369368|none                        |reviewed
             status|                            |

--- Comment #38 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
Review of attachment 369368:
 --> (https://bugzilla.gnome.org/review?bug=772841&attachment=369368)

Even though I'm sure the fallback is unlikely to be used, I think the
implementation of that fallback should be better. As we request a pool from
downstream, we should also do better with buffer that would have multiple
memory. A unit test with downstream providing pool would also be nice.

::: gst/udp/gstudpsrc.c
@@ +837,3 @@
   p_saddr = (udpsrc->retrieve_sender_address) ? &saddr : NULL;

+  if (!gst_buffer_map (outbuf, &info, GST_MAP_READWRITE))

That is not ideal, if downstream setup buffers with multiple memory in it, this
will merge them. You can use the ivec to prevent this.

@@ +843,3 @@
+  ivec[0].size = info.size;
+
+  /* Prepare memory in case the data size exceeds mtu */

s/mtu/buffer size/ because the size could have been set by downstream
allocation reply.

@@ +855,3 @@
+
+    udpsrc->extra_mem =
+        gst_allocator_alloc (allocator, MAX_IPV4_UDP_PACKET_SIZE, &params);

I'm not sure what the size limit for the vector, but wouldn't it be better to
add multiple buffers, this way if you have a 1400 mtu and downstream allocates
700, you have two zero copy buffers. All we need is to setup enough buffer in
the vect so that MAX_IPV4_UDP_PACKET_SIZE is reached.

@@ +983,2 @@
+  if (res > udpsrc->mtu) {
+    gst_buffer_append_memory (outbuf, udpsrc->extra_mem);

The way our pool works, this will kill it. All memory will be freed when they
come back because the "memory" got modified. Better use a buffer list.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.