A static list of 64 mbufs was being reused in Rx function.
This caused two errors:
1) If more than 64 buffers were requested in a single burst,
only the last 64 buffers are returned, the others are lost.
2) Application will free the mbuf being returned, but the receive
function will reuse the buffer anyway. If some other allocation
is done, there is suddenly multiple writers for the same mbuf.
It is fixed by allocating mbuf on demand.
In the same time, some length errors are fixed.
Reported-by: Mats Liljegren <mats.liljegren@enea.com> Reported-by: Robert Sanford <rsanford@prolexic.com> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Intel [Wed, 4 Dec 2013 09:00:00 +0000 (10:00 +0100)]
ixgbe: residual fix about resetting big Tx queues
Index overflow when resetting big queues was partially fixed in bcf457f8c0d64a5c (ixgbe: fix index overflow when resetting big Tx queues)
and better fixed in e8ae856140bce4e4 (igb/ixgbe: fix index overflow when resetting big queues)
But this version (1.5.2r0) has residues of the initial fix from 1.5.1r0.
Thomas Monjalon [Fri, 15 Nov 2013 11:08:10 +0000 (12:08 +0100)]
igb/ixgbe: fix index overflow when resetting big queues
Rings are resetted with a loop because memset cannot be used without
issuing a warning about volatile casting.
The index of the loop was a 16-bit variable which is sufficient for
ring entries number but not for the byte size of the whole ring.
The overflow happens when rings are configured for 4096 entries
(descriptor size is 16 bytes). The result is an endless loop.
It is fixed by indexing ring entries and resetting all bytes of the entry
with a simple assignment.
The descriptor initializer is zeroed thanks to its static declaration.
There already was a fix for ixgbe Tx only
(commit bcf457f8c0d64a5cb094fd55836b324bddb930b6).
It is reverted to use the same fix everywhere (Rx/Tx for igb/ixgbe).
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com> Acked-by: Ivan Boule <ivan.boule@6wind.com>
Intel [Fri, 8 Nov 2013 02:00:00 +0000 (03:00 +0100)]
app/cmdline_test: fix build without app/test
This application is built if LIBRTE_CMDLINE is enabled.
But there was no enabled source file if APP_TEST is disabled.
Let's consider that CONFIG_RTE_APP_TEST apply only on app/test.
Intel [Fri, 8 Nov 2013 02:00:00 +0000 (03:00 +0100)]
ixgbe: fix index overflow when resetting big Tx queues
The index of the loop was a 16-bit variable which is sufficient for
ring entries number but not for the byte size of the whole ring.
The overflow happens when queue rings are configured for 4096 entries
(descriptor size is 16 bytes). The result is an endless loop.
Intel [Fri, 8 Nov 2013 02:00:00 +0000 (03:00 +0100)]
ethdev: add bypass logic
An overview of bypass logic can be seen in this document:
http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ethernet-server-bypass-adapter-x520-x540-family-brief.pdf
In case of multi-process application, the secondary process can initialize
the driver without configuring queues. In this case the Rx/Tx functions
were not initialized because it was only done in queue setup.
Fix by reproducing the same behaviour as in eth_ixgbe_dev_init().
In case of multi-process application, the secondary process can initialize
the driver without configuring queues. In this case the Rx/Tx functions
were not initialized because it was only done in queue setup.
Fix by reproducing the same behaviour as in eth_igb_dev_init().
mem: retry malloc with smaller block size when failure
rte_malloc try to allocate memzone blocks with a minimum size.
It it fails, it retries for a smaller size than the standard one.
It will really fail if it cannot allocate block of the requested size.
The pause instruction is part of SSE2 extensions.
Note that some compilers define _mm_pause as "rep; nop" instead of "pause".
For compatible processors, they are equivalent.
http://www.intel.com/Assets/PDF/manual/325383.pdf:
"
When executing a spin-wait loop, a Pentium 4 or Intel Xeon processor suffers
a severe performance penalty when exiting the loop because it detects a
possible memory order violation.
The PAUSE instruction provides a hint to the processor that the code sequence
is a spin-wait loop. The processor uses this hint to avoid the memory order
violation in most situations, which greatly improves processor performance.
"