cmdline_numtype member names clash with Windows system identifiers.
Add RTE_ prefix to cmdline constants to avoid this and possible
future conflicts.
Suggested-by: Ranjit Menon <ranjit.menon@intel.com>
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Ranjit Menon <ranjit.menon@intel.com>
Acked-by: Jie Zhou <jizh@microsoft.com>
Tested-by: Jie Zhou <jizh@microsoft.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
The command line parameter --mbuf-size is updated, it can handle
the multiple values like the following:
--mbuf-size=2176,512,768,4096
specifying the creation the extra memory pools with the requested
mbuf data buffer sizes. If some buffer split feature is engaged
the extra memory pools can be used to configure the Rx queues
with rte_the_dev_rx_queue_setup_ex().
The extra pools are created with requested sizes, and pool names
are assigned with appended index: mbuf_pool_socket_%socket_%index.
Index zero is used to specify the first mandatory pool to maintain
compatibility with existing code.
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
The ethdev port id should be 16 bits now. This patch changes the
variable size of port id in applications from 8 bits to 16 bits.
Fixes: e977e4199a8d ("app/testpmd: add commands to load/unload BPF filters")
Fixes: 46cf97e4bbfa ("eventdev: add test for eth Tx adapter")
Cc: stable@dpdk.org
Signed-off-by: Chenbo Xia <chenbo.xia@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
There is a common macro __rte_unused, avoiding warnings,
which is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Extend struct rte_bpf_xsym with new fields to provide information about:
- for variables - type and size
- for functions - number of arguments and type/size of each argument
and return value
Such information would allow validate code to perform
more extensive checking on input BPF program and catch
misbehaving BPF code.
That change would cause ABI/API breakage for librte_bpf.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
