Tested it with various packet formats and sizes in gnrc_networking on samr21-xpro and the following patch to be able to check for memory leaks:

diff --git a/examples/gnrc_networking/main.c b/examples/gnrc_networking/main.c
index 6301f42..52637ca 100644
--- a/examples/gnrc_networking/main.c
+++ b/examples/gnrc_networking/main.c
@@ -22,14 +22,24 @@
 
 #include "shell.h"
 #include "msg.h"
+#include "net/gnrc/pktbuf.h"
 
 #define MAIN_QUEUE_SIZE     (8)
 static msg_t _main_msg_queue[MAIN_QUEUE_SIZE];
 
 extern int udp_cmd(int argc, char **argv);
 
+static int pktbuf_cmd(int argc, char **argv)
+{
+    (void)argc;
+    (void)argv;
+    gnrc_pktbuf_stats();
+    return 0;
+}
+
 static const shell_command_t shell_commands[] = {
     { "udp", "send data over UDP and listen on UDP ports", udp_cmd },
+    { "pktbuf", "---", pktbuf_cmd },
     { NULL, NULL, NULL }
 };
 

All seems well.

I don't see the 'big benefit' behind this but I can confirm it improves performance by about 1-1,5% (evaluated with my l2 reflector). I tested with a UDP application sending packets with payloads: 0:1:1210 Bytes. Additionally I tried ping6 with gnrc_networking and different payloads (10, 100, 500, 1210 Bytes). All went well. Pleas rebase

I don't see the benefit of the realloc in general, either. I mean, the most expensive (and sometimes problematic) part is the initial read without a buffer to get bytes_expected.

How large can the error (size diff) be for nbytes <= bytes_expected, anyway? Hence, it might even be worth considering to remove the realloc completely to save some code and checks, and live with the marginal error of wasting some bytes in the packet buffer.

Otherwise one could argue, that we could save the first read to get bytes_expected and simply always realloc.

@miri64 do you personally think this change is useful? It mainly changes your own code.

@PeterKietzmann wasn't this based on your recommendation, that realloc is causing timing problems (at least from what I remember). As such, I think this is useful, yes.

Ping @PeterKietzmann?

This did not fix the actual performance regression back then. But at least it improved processing at about ~1% or so. Anyway, both @smlng and me seem to be unconfined about the usefulness of this PR. That's why I'm asking for your personal opinion, since you wrote the initial code. I won't NACK this PR. So in case you are in favor of this PR, please rebase.

The code was originally by @kaspar030, but I think it is useful, as it frees wasted packet buffer space as soon as possible. As to if we could just remove the gnrc_pktbuf_realloc() as proposed by @smlng: might be, but we should evaluate this first.

I would need to redo this PR for gnrc_netif2 anyway, so if you don't think it is useful and since no-one seems to be interested in this at the moment, I close it as memo.