Hi,
ethtool not supported intel 82574 chip
has any plan?
Thanks.
fandunqiu
According to Intel Developer's Manual:
"The RDTSC instruction is not a serializing instruction. It does not
necessarily wait
until all previous instructions have been executed before reading the counter.
Simi-
larly, subsequent instructions may begin execution before the read operation is
per
It may happen that DPDK application gets killed while having
acquired locks on the ethernet hardware, causing these locks to
be never released. On next restart of the application, DPDK
skip those ports because it can not acquire the lock,
this may cause some ports (or even complete board if SMBI is
It may happen that DPDK application gets killed while having
acquired locks on the ethernet hardware, causing these locks to
be never released. On next restart of the application, DPDK
skip those ports because it can not acquire the lock,
this may cause some ports (or even complete board if SMBI is
Hi,
Can the patch be reworked to keep changes under librte_pmd_ixgbe/ixgbe
directory untouched?
Those files are derived directly from the BSD driver baseline, and any changes
will make future merges of newer code more challenging.
The changes should be limited to files in the librte_pmd_ixgbe dir
This is my init function:
pktmbuf_pool[socketid] = rte_mempool_create(
name,
APP_DEFAULT_MEMPOOL_BUFFERS,
APP_DEFAULT_MBUF_SIZE,
APP_DEFAULT_MEMPOOL_CACHE_SIZE,
sizeof(struct rte_pktmbuf_pool_private),
rte_pktmbuf_pool_init, NULL,
rte_pktmbuf_init, NULL,
socketid,
0);
I copied it from a s
According to Intel Developer's Manual:
"The RDTSC instruction is not a serializing instruction. It does not
necessarily wait
until all previous instructions have been executed before reading the counter.
Simi-
larly, subsequent instructions may begin execution before the read operation is
per
19/02/2014 13:41, Ananyev, Konstantin:
> Can the patch be reworked to keep changes under librte_pmd_ixgbe/ixgbe
> directory untouched? Those files are derived directly from the BSD driver
> baseline, and any changes will make future merges of newer code more
> challenging. The changes should be lim
Hi Mario,
Yes rte_pktmbuf_free doesn't touch data/data_len fields.
In fact for 'normal' mbuf it would only update refcnt.
It is responsibility of alloc path to reset all mbuf fields to some initial
values.
Usually it is done by: rte_pktmbuf_alloc()->rte_pktmbuf_reset().
If the code path doesn't us
Hi Thomas,
I am afraid I couldn't send you an url we are using.
We take it from internal Intel ND repository.
Though I think, that latest available to download from Intel ixgbe driver for
FreeBSD should have pretty close codebase.
As a rule of thumb in our internal policy: we take shared code fro
10 matches
Mail list logo
