Re: [dpdk-dev] [PATCH v1] doc: update release notes for 21.02
On Fri, 12 Feb 2021 00:33:35 +0100, Thomas Monjalon wrote: > 11/02/2021 13:08, Mcnamara, John: > > Also, there probably should be a note about the change to pmdinfogen > > in this release. I didn't know enough about it to add it myself. > > Yes it is a rewrite of a build tool. > The real new feature is the support of Windows for pmdinfo. > > +Cc Dmitry for helping with the wording. * **Added Windows support to pmdinfogen.** PMD information strings are added for Windows as well as for other OS. Extracting them from Windows DLLs is not yet supported. A build-time tool pmdinfogen is rewritten in Python, thus native compiler and libelf are not required for build machine anymore, but pyelftools build-time dependency is added. Feel free to use and/or adjust.
Re: [dpdk-dev] [dpdklab] Re: [dpdk-ci] [CI] SPDK compilation failures @ DPDK community lab
Hi, As Aaron noted this was result of rte_ethdev depending on rte_net. On SPDK side rte_net was included in default compilation with vhost component, but since vhost is disabled in the UNH lab tests with SPDK it showed up as missing. A fix for that is now submitted to SPDK: https://review.spdk.io/gerrit/c/spdk/spdk/+/6398 I'll let you know when it makes it's way to the v21.01.x branch. @Brandon Lo General question, is there particular reason to disable vhost [configure argument '--without-vhost'] in the UNH lab tests with SPDK ? I don't recall any identified issue and enabling it would increase the coverage of the compilation tests. Thanks, Tomek > -Original Message- > From: Aaron Conole > Sent: Thursday, February 11, 2021 3:02 PM > To: Brandon Lo > Cc: Zawadzki, Tomasz ; Lincoln Lavoie > ; dpdk...@iol.unh.edu; c...@dpdk.org; dev@dpdk.org; > s...@lists.01.org > Subject: Re: [dpdklab] Re: [dpdk-ci] [dpdk-dev] [CI] SPDK compilation failures > @ DPDK community lab > > Brandon Lo writes: > > > Hi again everyone, > > > > I have checked the pipelines with SPDK branch v21.01.x on the main DPDK > branch. > > It still seems to have an issue with compilation, and I have attached > > a log of a Fedora SPDK compilation. > > There are some undefined references to "rte_ether_unformat_addr" > > I will continue to look into this. If you have any ideas on how to fix > > this, please let me know. > > Looks like rte_ethdev depends on rte_net - maybe I missed something. > > Brandon, can we disable this test for the time being since it's been failing > for > a while now? Can you also send me the container image / definitions you're > using so that I can help work on this? > > > Thanks, > > Brandon > > > > On Tue, Feb 9, 2021 at 11:07 AM Brandon Lo wrote: > >> > >> Hi everyone, > >> > >> I will adjust the branches and watch over the first few pipelines to > >> make sure everything goes smoothly. > >> > >> Thanks for the update, > >> Brandon > >> > >> On Tue, Feb 9, 2021 at 10:13 AM Aaron Conole > wrote: > >> > > >> > "Zawadzki, Tomasz" writes: > >> > > >> > > Hi Lincoln, > >> > > > >> > > > >> > > > >> > > That patch in question is now merged to branch v21.01.x. > >> > > > >> > > >> > Good to know - I do still see a failure in the IOL job (even from a > >> > few hours ago). I suppose the lab side might need some adjustment, > too? > >> > > >> > > > >> > > The builds performed for latest SPDK and SPDK LTS, against > >> > > dpdk-main branch seem to be passing. Would love to hear if this > >> > > is what you are seeing on your end too. > >> > > > >> > > > >> > > > >> > > Thanks, > >> > > > >> > > Tomek > >> > > > >> > > > >> > > > >> > > From: Lincoln Lavoie > >> > > Sent: Monday, February 8, 2021 5:21 PM > >> > > To: Zawadzki, Tomasz > >> > > Cc: Aaron Conole ; Brandon Lo > >> > > ; dpdk...@iol.unh.edu; c...@dpdk.org; > >> > > dev@dpdk.org; s...@lists.01.org > >> > > Subject: Re: [dpdk-ci] [dpdk-dev] [CI] SPDK compilation failures > >> > > @ DPDK community lab > >> > > > >> > > > >> > > > >> > > Thanks Tomek, > >> > > > >> > > > >> > > > >> > > Can you let us know when the merge happens and we'll make sure > >> > > the next set of builds pass or see what the next failure is. :-P > >> > > > >> > > > >> > > > >> > > Cheers, > >> > > Lincoln > >> > > > >> > > > >> > > > >> > > On Mon, Feb 8, 2021 at 11:03 AM Zawadzki, Tomasz > wrote: > >> > > > >> > > Hi Aaron, > >> > > > >> > > Thank you for reporting this ! > >> > > > >> > > This is an issue with rte_power now depending on rte_ethdev, which > was resolved on latest SPDK. > >> > > > >> > > I believe that UNH lab verifies DPDK patches against SPDK branch > >> > > for latest release. Which after the very recent SPDK release, > >> > > would be v21.01.x: > >> > > https://github.com/spdk/spdk/tree/v21.01.x > >> > > > >> > > The fix has been backported to that branch and should be merged > shortly: > >> > > https://review.spdk.io/gerrit/c/spdk/spdk/+/6320 > >> > > > >> > > Thanks, > >> > > Tomek > >> > > > >> > > > -Original Message- > >> > > > From: dev On Behalf Of Aaron Conole > > >> > > Sent: Monday, February 8, 2021 4:21 PM > To: Brandon Lo > >> > > > Cc: dpdk...@iol.unh.edu; c...@dpdk.org; > >> > > dev@dpdk.org; s...@lists.01.org > Subject: [dpdk-dev] [CI] SPDK > >> > > compilation failures @ DPDK community lab > > Greetings, > > > >> > > I've noticed that recently SPDK compilation in the UNH community > >> > > lab seems > to be failing, and I don't see an obvious reason for the > failure. > >> > > > The logs haven't been too helpful - it appears that there is a > >> > > symbol that isn't > available when linking. > >> > > > > >> > > > Job details (for example): > >> > > > https://lab.dpdk.org/results/dashboard/results/results- > >> > > > > >> > > > uploads/test_runs/2363efb43157465db3228c34c00ebd57/log_upload_fil > >> > > e/20 > 21/2/dpdk_f6f2d2240153_15524_2021-02-04_22-59-59_NA.zip > >> > > > > >> > > > Is
[dpdk-dev] [RFC PATCH] eventdev: use shared memory to store timer adapter
It is not possible for secondary process to arm timer as timer adapter
is not stored in shared memory. Using shared memory allows the secondary
to lookup adapters and arm them.
Signed-off-by: Shijith Thotton
---
drivers/event/octeontx/timvf_evdev.c | 20 +-
drivers/event/octeontx/timvf_worker.c | 12 +-
drivers/event/octeontx2/otx2_tim_evdev.c | 28 +--
drivers/event/octeontx2/otx2_tim_worker.c | 4 +-
lib/librte_eventdev/rte_event_timer_adapter.c | 193 ++
lib/librte_eventdev/rte_event_timer_adapter.h | 58 --
.../rte_event_timer_adapter_pmd.h | 31 ---
7 files changed, 186 insertions(+), 160 deletions(-)
diff --git a/drivers/event/octeontx/timvf_evdev.c
b/drivers/event/octeontx/timvf_evdev.c
index 8af4d6e37..ee93c87b5 100644
--- a/drivers/event/octeontx/timvf_evdev.c
+++ b/drivers/event/octeontx/timvf_evdev.c
@@ -39,10 +39,10 @@ static void
timvf_ring_info_get(const struct rte_event_timer_adapter *adptr,
struct rte_event_timer_adapter_info *adptr_info)
{
- struct timvf_ring *timr = adptr->data->adapter_priv;
+ struct timvf_ring *timr = adptr->data.adapter_priv;
adptr_info->max_tmo_ns = timr->max_tout;
adptr_info->min_resolution_ns = timr->tck_nsec;
- rte_memcpy(&adptr_info->conf, &adptr->data->conf,
+ rte_memcpy(&adptr_info->conf, &adptr->data.conf,
sizeof(struct rte_event_timer_adapter_conf));
}
@@ -123,7 +123,7 @@ timvf_ring_start(const struct rte_event_timer_adapter
*adptr)
uintptr_t pool;
struct timvf_ctrl_reg rctrl;
struct timvf_mbox_dev_info dinfo;
- struct timvf_ring *timr = adptr->data->adapter_priv;
+ struct timvf_ring *timr = adptr->data.adapter_priv;
ret = timvf_mbox_dev_info_get(&dinfo);
if (ret < 0 || ret != sizeof(struct timvf_mbox_dev_info))
@@ -210,7 +210,7 @@ timvf_ring_start(const struct rte_event_timer_adapter
*adptr)
static int
timvf_ring_stop(const struct rte_event_timer_adapter *adptr)
{
- struct timvf_ring *timr = adptr->data->adapter_priv;
+ struct timvf_ring *timr = adptr->data.adapter_priv;
struct timvf_ctrl_reg rctrl = {0};
rctrl.rctrl0 = timvf_read64((uint8_t *)timr->vbar0 + TIM_VRING_CTL0);
rctrl.rctrl1 = timvf_read64((uint8_t *)timr->vbar0 + TIM_VRING_CTL1);
@@ -225,7 +225,7 @@ timvf_ring_stop(const struct rte_event_timer_adapter *adptr)
static int
timvf_ring_create(struct rte_event_timer_adapter *adptr)
{
- struct rte_event_timer_adapter_conf *rcfg = &adptr->data->conf;
+ struct rte_event_timer_adapter_conf *rcfg = &adptr->data.conf;
uint16_t free_idx = UINT16_MAX;
unsigned int mp_flags = 0;
struct ssovf_evdev *edev;
@@ -245,7 +245,7 @@ timvf_ring_create(struct rte_event_timer_adapter *adptr)
if (timr == NULL)
return -ENOMEM;
- adptr->data->adapter_priv = timr;
+ adptr->data.adapter_priv = timr;
/* Check config parameters. */
if ((rcfg->clk_src != RTE_EVENT_TIMER_ADAPTER_CPU_CLK) &&
(!rcfg->timer_tick_ns ||
@@ -364,7 +364,7 @@ timvf_ring_create(struct rte_event_timer_adapter *adptr)
static int
timvf_ring_free(struct rte_event_timer_adapter *adptr)
{
- struct timvf_ring *timr = adptr->data->adapter_priv;
+ struct timvf_ring *timr = adptr->data.adapter_priv;
struct ssovf_evdev *edev;
int i;
@@ -380,7 +380,7 @@ timvf_ring_free(struct rte_event_timer_adapter *adptr)
rte_mempool_free(timr->chunk_pool);
rte_free(timr->bkt);
timvf_release_ring(timr->tim_ring_id);
- rte_free(adptr->data->adapter_priv);
+ rte_free(adptr->data.adapter_priv);
return 0;
}
@@ -388,7 +388,7 @@ static int
timvf_stats_get(const struct rte_event_timer_adapter *adapter,
struct rte_event_timer_adapter_stats *stats)
{
- struct timvf_ring *timr = adapter->data->adapter_priv;
+ struct timvf_ring *timr = adapter->data.adapter_priv;
uint64_t bkt_cyc = rte_rdtsc() - timr->ring_start_cyc;
stats->evtim_exp_count = timr->tim_arm_cnt;
@@ -401,7 +401,7 @@ timvf_stats_get(const struct rte_event_timer_adapter
*adapter,
static int
timvf_stats_reset(const struct rte_event_timer_adapter *adapter)
{
- struct timvf_ring *timr = adapter->data->adapter_priv;
+ struct timvf_ring *timr = adapter->data.adapter_priv;
timr->tim_arm_cnt = 0;
return 0;
diff --git a/drivers/event/octeontx/timvf_worker.c
b/drivers/event/octeontx/timvf_worker.c
index 50790e199..2e33ddd33 100644
--- a/drivers/event/octeontx/timvf_worker.c
+++ b/drivers/event/octeontx/timvf_worker.c
@@ -70,7 +70,7 @@ timvf_timer_arm_burst_sp(const struct rte_event_timer_adapter
*adptr,
int ret;
uint16_t index;
struct tim_mem_entry entry;
- struct timvf_ring *timr = adptr->data->adapter_priv;
+ struct timvf_ring *timr
Re: [dpdk-dev] [RFC PATCH] eventdev: use shared memory to store timer adapter
>-Original Message-
>From: Shijith Thotton
>Sent: Friday, February 12, 2021 3:44 PM
>To: Erik Gabriel Carrillo
>Cc: Shijith Thotton ; Pavan Nikhilesh
>Bhagavatula ; Jerin Jacob Kollanukkaran
>; dev@dpdk.org
>Subject: [RFC PATCH] eventdev: use shared memory to store timer
>adapter
>
>It is not possible for secondary process to arm timer as timer adapter
>is not stored in shared memory. Using shared memory allows the
>secondary
>to lookup adapters and arm them.
>
>Signed-off-by: Shijith Thotton
>---
> drivers/event/octeontx/timvf_evdev.c | 20 +-
> drivers/event/octeontx/timvf_worker.c | 12 +-
> drivers/event/octeontx2/otx2_tim_evdev.c | 28 +--
> drivers/event/octeontx2/otx2_tim_worker.c | 4 +-
> lib/librte_eventdev/rte_event_timer_adapter.c | 193 ++--
>--
> lib/librte_eventdev/rte_event_timer_adapter.h | 58 --
> .../rte_event_timer_adapter_pmd.h | 31 ---
> 7 files changed, 186 insertions(+), 160 deletions(-)
>
>diff --git a/lib/librte_eventdev/rte_event_timer_adapter.c
>b/lib/librte_eventdev/rte_event_timer_adapter.c
>index dd7b83087..682b1c3c2 100644
>--- a/lib/librte_eventdev/rte_event_timer_adapter.c
>+++ b/lib/librte_eventdev/rte_event_timer_adapter.c
>@@ -26,14 +26,14 @@
> #include "rte_event_timer_adapter.h"
> #include "rte_event_timer_adapter_pmd.h"
>
>-#define DATA_MZ_NAME_MAX_LEN 64
>-#define DATA_MZ_NAME_FORMAT
>"rte_event_timer_adapter_data_%d"
>+#define EVTIM_MZ_NAME_MAX_LEN 64
>+#define EVTIM_MZ_NAME_FORMAT "rte_event_timer_adapter_%d"
>
> RTE_LOG_REGISTER(evtim_logtype, lib.eventdev.adapter.timer,
>NOTICE);
> RTE_LOG_REGISTER(evtim_buffer_logtype, lib.eventdev.adapter.timer,
>NOTICE);
> RTE_LOG_REGISTER(evtim_svc_logtype,
>lib.eventdev.adapter.timer.svc, NOTICE);
>
>-static struct rte_event_timer_adapter
>adapters[RTE_EVENT_TIMER_ADAPTER_NUM_MAX];
>+static struct rte_event_timer_adapter **adapters;
>
> static const struct rte_event_timer_adapter_ops swtim_ops;
>
>@@ -72,8 +72,8 @@ default_port_conf_cb(uint16_t id, uint8_t
>event_dev_id, uint8_t *event_port_id,
>
> RTE_SET_USED(event_dev_id);
>
>- adapter = &adapters[id];
>- dev = &rte_eventdevs[adapter->data->event_dev_id];
>+ adapter = adapters[id];
>+ dev = &rte_eventdevs[adapter->data.event_dev_id];
> dev_id = dev->data->dev_id;
> dev_conf = dev->data->dev_conf;
>
>@@ -118,6 +118,31 @@ default_port_conf_cb(uint16_t id, uint8_t
>event_dev_id, uint8_t *event_port_id,
> return ret;
> }
>
>+static int
>+rte_event_timer_adapter_init(void)
>+{
>+ const char *name = "rte_event_timer_adapter_array";
>+ const struct rte_memzone *mz;
>+ unsigned int sz;
>+
>+ sz = sizeof(*adapters) *
>RTE_EVENT_TIMER_ADAPTER_NUM_MAX;
>+ sz = RTE_ALIGN(sz, RTE_CACHE_LINE_SIZE);
>+
>+ mz = rte_memzone_lookup(name);
>+ if (mz == NULL) {
>+ mz = rte_memzone_reserve_aligned(name, sz,
>rte_socket_id(), 0,
>+
>RTE_CACHE_LINE_SIZE);
>+ if (mz == NULL) {
>+ EVTIM_LOG_ERR("failed to reserve memzone
>err = %"
>+ PRId32, rte_errno);
>+ return -rte_errno;
>+ }
>+ }
>+
>+ adapters = mz->addr;
Moving adapter array to shared memory wouldn't work as adapter->ops would also
be on shared mem
and secondary processes would just replace the ops function pointers to its
text section resulting in
undefined behavior on primary and other secondaries.
The Programming model should be one process should create the timer adapter and
other primary/secondaries
Should do a rte_event_timer_adapter_lookup before using the adapter_id to
arm/cancel timers.
The fixup/sync between primary and secondary is done in
`rte_event_timer_adapter_lookup`.
Maybe we should update the documentation regarding this.
Regards,
Pavan.
>+ return 0;
>+}
>+
> struct rte_event_timer_adapter *
> rte_event_timer_adapter_create(const struct
>rte_event_timer_adapter_conf *conf)
> {
>@@ -134,7 +159,7 @@ rte_event_timer_adapter_create_ext(
> uint16_t adapter_id;
> struct rte_event_timer_adapter *adapter;
> const struct rte_memzone *mz;
>- char mz_name[DATA_MZ_NAME_MAX_LEN];
>+ char mz_name[EVTIM_MZ_NAME_MAX_LEN];
> int n, ret;
> struct rte_eventdev *dev;
>
>@@ -143,6 +168,11 @@ rte_event_timer_adapter_create_ext(
> return NULL;
> }
>
>+ if (adapters == NULL) {
>+ if (rte_event_timer_adapter_init())
>+ return NULL;
>+ }
>+
> /* Check eventdev ID */
> if (!rte_event_pmd_is_valid_dev(conf->event_dev_id)) {
> rte_errno = EINVAL;
>@@ -159,49 +189,51 @@ rte_event_timer_adapter_create_ext(
> }
>
> /* Check adapter ID not already allocated */
>- adapter = &adapters[adapter_id];
>- if (adapter->allocated) {
>+ adapter = adapters[adapter_id];
>+ if (adapter) {
>+ EVTIM_LOG_E
[dpdk-dev] [PATCH] doc: add pmdinfogen rewrite to release notes
From: Dmitry Kozlyuk
The build tool pmdinfogen was rewritten in DPDK 21.02,
adding Windows support.
There is a new build-time dependency: pyelftools.
Fixes: f0f93a7adfee ("buildtools: use Python pmdinfogen")
Fixes: 6b19edcb663c ("build: enable pmdinfogen for Windows")
Signed-off-by: Dmitry Kozlyuk
Signed-off-by: Thomas Monjalon
---
doc/guides/rel_notes/release_21_02.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/doc/guides/rel_notes/release_21_02.rst
b/doc/guides/rel_notes/release_21_02.rst
index 64e220f2ac..786c70455d 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -180,6 +180,13 @@ New Features
tests and output graphed results to PDF files.
See the :doc:`../tools/cryptoperf` guide for more details.
+* **Added Windows support to pmdinfogen.**
+
+ PMD information strings were added for Windows as well as for other OS.
+ Extracting them from Windows DLLs is not yet supported.
+ The build-time tool pmdinfogen was rewritten in Python,
+ thus libelf dependency was replaced with pyelftools as new build dependency.
+
* **Added support for build-time checking of header includes.**
A new build option ``check_includes`` has been added, which, when enabled,
--
2.30.0
[dpdk-dev] [PATCH] net/mlx5: fix external buffer pool registration for Rx queue
On Rx queue creation the mlx5 PMD registers the data buffers of the
specified pools for DMA operations. It scans the mem_list of the pools
and creates the MRs (DMA related NIC objects) for the chunks found.
If the pool is created with rte_pktmbuf_pool_create_extbuf() and
refers to the external attached buffers (whose are in the area of
application responsibility and it should explicitly register the
data buffer memory for DMA with rte_dev_dma_map() call) the chunks
contain the mbuf structures only, w/o any built-in data buffers.
Hence, DMA with mlx5 NIC never happens to this area and there is
no need to create MRs for these ones.
The extra not needed MRs were created for the pools with external
buffers causing MR cache load and performance was slightly affected.
The patch checks the mbuf pool type and skips MR creation for the
pools with external buffers.
Fixes: bdb8e5b1ea7b ("net/mlx5: allow allocated mbuf with external buffer")
Cc: sta...@dpdk.org
Signed-off-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5_mr.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/mlx5/mlx5_mr.c b/drivers/net/mlx5/mlx5_mr.c
index 8b20ee3f83..da4e91fc24 100644
--- a/drivers/net/mlx5/mlx5_mr.c
+++ b/drivers/net/mlx5/mlx5_mr.c
@@ -535,7 +535,18 @@ mlx5_mr_update_mp(struct rte_eth_dev *dev, struct
mlx5_mr_ctrl *mr_ctrl,
.mr_ctrl = mr_ctrl,
.ret = 0,
};
+ uint32_t flags = rte_pktmbuf_priv_flags(mp);
+ if (flags & RTE_PKTMBUF_POOL_F_PINNED_EXT_BUF) {
+ /*
+* The pinned external buffer should be registered for DMA
+* operations by application. The mem_list of the pool contains
+* the list of chunks with mbuf structures w/o built-in data
+* buffers and DMA actually does not happen there, no need
+* to create MR for these chunks.
+*/
+ return 0;
+ }
DRV_LOG(DEBUG, "Port %u Rx queue registering mp %s "
"having %u chunks.", dev->data->port_id,
mp->name, mp->nb_mem_chunks);
--
2.18.1
Re: [dpdk-dev] [PATCH] usertools: check 0-division with hugepage size
On 11-Feb-21 10:05 PM, Thomas Monjalon wrote:
The default page size can be None, and the page size from user request
can be 0 kB if lower than 1024. In these cases, a division will fail.
In order to avoid a Python exception, the page size is checked
and an error message "Invalid page size" is printed.
A similar error message is printed in set_hugepages()
if the size is not supported, except at this stage the message can be
completed with "Valid page sizes".
Unfortunately the first check is too early to print such information.
A third error message can be printed in a different place (get_memsize)
in case of a format issue, e.g. a negative size.
The function get_memsize() is also used for total requested size,
so the error message "not a valid page size" was potentially wrong.
This message is replaced with the more general "is not a valid size".
Signed-off-by: Thomas Monjalon
---
usertools/dpdk-hugepages.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/usertools/dpdk-hugepages.py b/usertools/dpdk-hugepages.py
index fb368b6933..c1f2549ec0 100755
--- a/usertools/dpdk-hugepages.py
+++ b/usertools/dpdk-hugepages.py
@@ -29,7 +29,7 @@ def get_memsize(arg):
'''Convert memory size with suffix to kB'''
match = re.match(r'(\d+)([' + BINARY_PREFIX + r']?)$', arg.upper())
if match is None:
-sys.exit('{} is not a valid page size'.format(arg))
+sys.exit('{} is not a valid size'.format(arg))
num = float(match.group(1))
suffix = match.group(2)
if suffix == "":
@@ -254,6 +254,8 @@ def main():
pagesize_kb = get_memsize(args.pagesize)
else:
pagesize_kb = default_pagesize()
+if pagesize_kb is None or pagesize_kb == 0:
+sys.exit("Invalid page size: {}kB".format(pagesize_kb))
Both None and 0 evaluate to False for boolean comparisons, so you can
replace it with:
if not pagesize_kb:
sys.exit(...)
if args.clear:
clear_pages()
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH] usertools: check 0-division with hugepage size
12/02/2021 12:27, Burakov, Anatoly:
> On 11-Feb-21 10:05 PM, Thomas Monjalon wrote:
> > The default page size can be None, and the page size from user request
> > can be 0 kB if lower than 1024. In these cases, a division will fail.
> > In order to avoid a Python exception, the page size is checked
> > and an error message "Invalid page size" is printed.
> >
> > A similar error message is printed in set_hugepages()
> > if the size is not supported, except at this stage the message can be
> > completed with "Valid page sizes".
> > Unfortunately the first check is too early to print such information.
> >
> > A third error message can be printed in a different place (get_memsize)
> > in case of a format issue, e.g. a negative size.
> > The function get_memsize() is also used for total requested size,
> > so the error message "not a valid page size" was potentially wrong.
> > This message is replaced with the more general "is not a valid size".
> >
> > Signed-off-by: Thomas Monjalon
> > ---
> > @@ -254,6 +254,8 @@ def main():
> > pagesize_kb = get_memsize(args.pagesize)
> > else:
> > pagesize_kb = default_pagesize()
> > +if pagesize_kb is None or pagesize_kb == 0:
> > +sys.exit("Invalid page size: {}kB".format(pagesize_kb))
>
> Both None and 0 evaluate to False for boolean comparisons, so you can
> replace it with:
>
> if not pagesize_kb:
> sys.exit(...)
Oh yes better :)
Re: [dpdk-dev] [PATCH 21.05] app/testpmd: support show Rx queue count
On 2/11/2021 7:44 PM, Lance Richardson wrote:
Add support for querying receive queue count in order to allow
the rte_eth_dev rx_queue_count() API to be exercised and tested.
+1 to adding this feature, but the naming is a little misleading, "Rx queue
count", it looks like it will print the number of Rx queues, and the API has the
same problem indeed.
Can you please clarify it that it is to get number of used descriptor in a Rx
queue?
And "used descriptor" part also needs some explanation I think.
Signed-off-by: Lance Richardson
---
app/test-pmd/cmdline.c | 65 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 6 ++
2 files changed, 71 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 59722d268..6e2fe57a6 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -16699,6 +16699,70 @@ cmdline_parse_inst_t cmd_show_rx_tx_desc_status = {
},
};
+/* *** display rx queue count *** */
+struct cmd_show_rx_queue_count_result {
+ cmdline_fixed_string_t cmd_show;
+ cmdline_fixed_string_t cmd_port;
+ cmdline_fixed_string_t cmd_rxq;
+ cmdline_fixed_string_t cmd_count;
+ portid_t cmd_pid;
+ portid_t cmd_qid;
+};
+
+static void
+cmd_show_rx_queue_count_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_show_rx_queue_count_result *res = parsed_result;
+ int rc;
+
+ if (!rte_eth_dev_is_valid_port(res->cmd_pid)) {
+ printf("invalid port id %u\n", res->cmd_pid);
+ return;
+ }
+
+ rc = rte_eth_rx_queue_count(res->cmd_pid, res->cmd_qid);
+ if (rc < 0) {
+ printf("Invalid queueid = %d\n", res->cmd_qid);
+ return;
+ }
+ printf("Used desc count = %d\n", rc);
+}
+
+cmdline_parse_token_string_t cmd_show_rx_queue_count_show =
+ TOKEN_STRING_INITIALIZER(struct cmd_show_rx_queue_count_result,
+ cmd_show, "show");
+cmdline_parse_token_string_t cmd_show_rx_queue_count_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_show_rx_queue_count_result,
+ cmd_port, "port");
+cmdline_parse_token_num_t cmd_show_rx_queue_count_pid =
+ TOKEN_NUM_INITIALIZER(struct cmd_show_rx_queue_count_result,
+ cmd_pid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_show_rx_queue_count_rxq =
+ TOKEN_STRING_INITIALIZER(struct cmd_show_rx_queue_count_result,
+ cmd_rxq, "rxq");
+cmdline_parse_token_num_t cmd_show_rx_queue_count_qid =
+ TOKEN_NUM_INITIALIZER(struct cmd_show_rx_queue_count_result,
+ cmd_qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_show_rx_queue_count_count =
+ TOKEN_STRING_INITIALIZER(struct cmd_show_rx_queue_count_result,
+ cmd_count, "count");
+cmdline_parse_inst_t cmd_show_rx_queue_count = {
+ .f = cmd_show_rx_queue_count_parsed,
+ .data = NULL,
+ .help_str = "show port rxq count",
There is already an existing command:
"show port rxq|txq desc status"
What do you think adding the new one as something like:
"show port rxq desc used count"
+ .tokens = {
+ (void *)&cmd_show_rx_queue_count_show,
+ (void *)&cmd_show_rx_queue_count_port,
+ (void *)&cmd_show_rx_queue_count_pid,
+ (void *)&cmd_show_rx_queue_count_rxq,
+ (void *)&cmd_show_rx_queue_count_qid,
+ (void *)&cmd_show_rx_queue_count_count,
+ NULL,
+ },
+};
+
/* Common result structure for set port ptypes */
struct cmd_set_port_ptypes_result {
cmdline_fixed_string_t set;
@@ -17098,6 +17162,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_config_tx_metadata_specific,
(cmdline_parse_inst_t *)&cmd_show_tx_metadata,
(cmdline_parse_inst_t *)&cmd_show_rx_tx_desc_status,
+ (cmdline_parse_inst_t *)&cmd_show_rx_queue_count,
(cmdline_parse_inst_t *)&cmd_set_raw,
(cmdline_parse_inst_t *)&cmd_show_set_raw,
(cmdline_parse_inst_t *)&cmd_show_set_raw_all,
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a45910b81..789ee7d27 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -266,6 +266,12 @@ Display information for a given port's RX/TX descriptor
status::
testpmd> show port (port_id) (rxq|txq) (queue_id) desc (desc_id) status
+show rxq count
+~
The '~' line length should be same as header length
+
+Display the number of ready descriptors on a given RX queue::
Can you please describe more, what is "ready descriptor"?
The 'rte_eth_rx_queue_count()' API should be returning number of descriptors
filled by HW.
+
+ testpmd> show port (po
Re: [dpdk-dev] [PATCH] doc: replace hugepages commands with dedicated tool
On 2/11/2021 6:16 PM, Thomas Monjalon wrote: The tool dpdk-hugepages.py, added in DPDK 20.11, is referenced in the guides instead of more complicate commands. The original Linux commands are kept in linux_gsg/sys_reqs.rst and nics/build_and_test.rst. Suggested-by: Stephen Hemminger Signed-off-by: Thomas Monjalon --- doc/guides/cryptodevs/octeontx.rst| 4 +--- doc/guides/cryptodevs/octeontx2.rst | 2 +- doc/guides/howto/lm_bond_virtio_sriov.rst | 6 +++--- doc/guides/howto/lm_virtio_vhost_user.rst | 6 +++--- doc/guides/linux_gsg/sys_reqs.rst | 2 ++ doc/guides/nics/build_and_test.rst| 6 ++ doc/guides/nics/mlx4.rst | 2 +- doc/guides/nics/mlx5.rst | 2 +- doc/guides/nics/virtio.rst| 2 +- doc/guides/sample_app_ug/vhost.rst| 2 +- 10 files changed, 20 insertions(+), 14 deletions(-) diff --git a/doc/guides/cryptodevs/octeontx.rst b/doc/guides/cryptodevs/octeontx.rst index d813cb2974..a39f3f3d02 100644 --- a/doc/guides/cryptodevs/octeontx.rst +++ b/doc/guides/cryptodevs/octeontx.rst @@ -107,9 +107,7 @@ applications. .. code-block:: console -echo 8 > /sys/kernel/mm/hugepages/hugepages-524288kB/nr_hugepages -mkdir /mnt/huge -mount -t hugetlbfs nodev /mnt/huge + dpdk-hugepages.py --setup 4G --pagesize 512M Example applications can now be executed with crypto operations offloaded to OCTEON TX crypto PMD. diff --git a/doc/guides/cryptodevs/octeontx2.rst b/doc/guides/cryptodevs/octeontx2.rst index a648a33cbc..d312eeb74c 100644 --- a/doc/guides/cryptodevs/octeontx2.rst +++ b/doc/guides/cryptodevs/octeontx2.rst @@ -123,7 +123,7 @@ Another way to bind the VF would be to use the ``dpdk-devbind.py`` script: * Ensure that sufficient huge pages are available for your application:: - echo 8 > /sys/kernel/mm/hugepages/hugepages-524288kB/nr_hugepages + dpdk-hugepages.py --setup 4G --pagesize 512M Refer to :ref:`linux_gsg_hugepages` for more details. diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst b/doc/guides/howto/lm_bond_virtio_sriov.rst index 16d86d122c..3e25480316 100644 --- a/doc/guides/howto/lm_bond_virtio_sriov.rst +++ b/doc/guides/howto/lm_bond_virtio_sriov.rst @@ -581,9 +581,9 @@ Set up DPDK in the Virtual Machine # virtio port is 03 # vf port is 04 - cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages - echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages - cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages + /root/dpdk/usertools/dpdk-hugepages.py --show + /root/dpdk/usertools/dpdk-hugepages.py --setup 2G + /root/dpdk/usertools/dpdk-hugepages.py --show Wouldn't be better to use 'dpdk-hugepages.py' only, or perhaps './usertools/dpdk-hugepages.py' but not full path. The dpdk path, '/root/dpdk/', assumption can be missleading.
Re: [dpdk-dev] [PATCH v1] doc: update release notes for 21.02
On Fri, Feb 12, 2021 at 12:33:35AM +0100, Thomas Monjalon wrote: > 11/02/2021 13:08, Mcnamara, John: > > > Thomas, > > > > I didn't remove the "Known Issues" section in case someone else > > adds something to it. If not you can remove it. > > OK, I will remove. > Should the new dependency on pyelftools be called out here? Since it's not a common package I think it needs to be emphasised as a new dependency and instructions on how to get it. > > Also, there probably should be a note about the change to pmdinfogen > > in this release. I didn't know enough about it to add it myself. > > Yes it is a rewrite of a build tool. > The real new feature is the support of Windows for pmdinfo. > > +Cc Dmitry for helping with the wording. > >
Re: [dpdk-dev] [PATCH v1] doc: update release notes for 21.02
12/02/2021 12:57, Bruce Richardson: > On Fri, Feb 12, 2021 at 12:33:35AM +0100, Thomas Monjalon wrote: > > 11/02/2021 13:08, Mcnamara, John: > > > > > Thomas, > > > > > > I didn't remove the "Known Issues" section in case someone else > > > adds something to it. If not you can remove it. > > > > OK, I will remove. > > Should the new dependency on pyelftools be called out here? Since it's not > a common package I think it needs to be emphasised as a new dependency and > instructions on how to get it. What do you think of this update? https://patches.dpdk.org/patch/87883/
Re: [dpdk-dev] [PATCH] doc: replace hugepages commands with dedicated tool
12/02/2021 12:55, Ferruh Yigit: > On 2/11/2021 6:16 PM, Thomas Monjalon wrote: > > --- a/doc/guides/howto/lm_bond_virtio_sriov.rst > > +++ b/doc/guides/howto/lm_bond_virtio_sriov.rst > > @@ -581,9 +581,9 @@ Set up DPDK in the Virtual Machine > > # virtio port is 03 > > # vf port is 04 > > > > - cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages > > - echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages > > - cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages > > + /root/dpdk/usertools/dpdk-hugepages.py --show > > + /root/dpdk/usertools/dpdk-hugepages.py --setup 2G > > + /root/dpdk/usertools/dpdk-hugepages.py --show > > Wouldn't be better to use 'dpdk-hugepages.py' only, or perhaps > './usertools/dpdk-hugepages.py' but not full path. > The dpdk path, '/root/dpdk/', assumption can be missleading. Using this fixed path is consistent with the rest of this howto. Maybe you would prefer a rewrite of the howto?
Re: [dpdk-dev] [PATCH v1] doc: update release notes for 21.02
On Fri, Feb 12, 2021 at 01:49:27PM +0100, Thomas Monjalon wrote: > 12/02/2021 12:57, Bruce Richardson: > > On Fri, Feb 12, 2021 at 12:33:35AM +0100, Thomas Monjalon wrote: > > > 11/02/2021 13:08, Mcnamara, John: > > > > > > > Thomas, > > > > > > > > I didn't remove the "Known Issues" section in case someone else > > > > adds something to it. If not you can remove it. > > > > > > OK, I will remove. > > > > Should the new dependency on pyelftools be called out here? Since it's > > not a common package I think it needs to be emphasised as a new > > dependency and instructions on how to get it. > > What do you think of this update? https://patches.dpdk.org/patch/87883/ > I think that is ok as an update for that particular section of "new features", but the fact is that that new feature introduces a new dependency for everyone, which means it may be missed for those who aren't interested in new features. Therefore, I think it should be called out somewhere else too, to really call attention to it. The reason I would suggest "known issues" is that it is a section that everyone looking at the release notes is likely to pay attention to. However, other options, such as a callout note at the top of the Release Notes i.e not in any particular section, might work as well. /Bruce
Re: [dpdk-dev] [PATCH v1] doc: update release notes for 21.02
12/02/2021 14:30, Bruce Richardson: > On Fri, Feb 12, 2021 at 01:49:27PM +0100, Thomas Monjalon wrote: > > 12/02/2021 12:57, Bruce Richardson: > > > On Fri, Feb 12, 2021 at 12:33:35AM +0100, Thomas Monjalon wrote: > > > > 11/02/2021 13:08, Mcnamara, John: > > > > > > > > > Thomas, > > > > > > > > > > I didn't remove the "Known Issues" section in case someone else > > > > > adds something to it. If not you can remove it. > > > > > > > > OK, I will remove. > > > > > > Should the new dependency on pyelftools be called out here? Since it's > > > not a common package I think it needs to be emphasised as a new > > > dependency and instructions on how to get it. > > > > What do you think of this update? https://patches.dpdk.org/patch/87883/ > > > I think that is ok as an update for that particular section of "new > features", but the fact is that that new feature introduces a new > dependency for everyone, which means it may be missed for those who aren't > interested in new features. Therefore, I think it should be called out > somewhere else too, to really call attention to it. The reason I would > suggest "known issues" is that it is a section that everyone looking at the > release notes is likely to pay attention to. However, other options, such > as a callout note at the top of the Release Notes i.e not in any particular > section, might work as well. I agree about the need, but I don't think adding something in known issues is visible enough. I will send a v2 with a note at the very beginning of the release notes.
[dpdk-dev] [PATCH v2] doc: add pmdinfogen rewrite to release notes
From: Dmitry Kozlyuk
The build tool pmdinfogen was rewritten in DPDK 21.02,
adding Windows support.
There is a new build-time dependency: pyelftools.
Fixes: f0f93a7adfee ("buildtools: use Python pmdinfogen")
Fixes: 6b19edcb663c ("build: enable pmdinfogen for Windows")
Signed-off-by: Dmitry Kozlyuk
Signed-off-by: Thomas Monjalon
---
doc/guides/rel_notes/release_21_02.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/doc/guides/rel_notes/release_21_02.rst
b/doc/guides/rel_notes/release_21_02.rst
index 64e220f2ac..99a559479b 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -20,6 +20,12 @@ DPDK Release 21.02
make doc-guides-html
xdg-open build/doc/html/guides/rel_notes/release_21_02.html
+.. note::
+
+ A dependency has been added for building DPDK on Linux or FreeBSD:
+ the Python module pyelftools (version 0.22 or greater),
+ often packaged as python3-pyelftools, is required.
+
New Features
@@ -180,6 +186,13 @@ New Features
tests and output graphed results to PDF files.
See the :doc:`../tools/cryptoperf` guide for more details.
+* **Added Windows support to pmdinfogen.**
+
+ PMD information strings were added for Windows as well as for other OS.
+ Extracting them from Windows DLL is not yet supported.
+ The build-time tool pmdinfogen was rewritten in Python,
+ thus libelf dependency was replaced with pyelftools as new build dependency.
+
* **Added support for build-time checking of header includes.**
A new build option ``check_includes`` has been added, which, when enabled,
--
2.30.0
Re: [dpdk-dev] [PATCH v2] doc: add pmdinfogen rewrite to release notes
On Fri, Feb 12, 2021 at 03:17:39PM +0100, Thomas Monjalon wrote:
> From: Dmitry Kozlyuk
>
> The build tool pmdinfogen was rewritten in DPDK 21.02,
> adding Windows support.
> There is a new build-time dependency: pyelftools.
>
> Fixes: f0f93a7adfee ("buildtools: use Python pmdinfogen")
> Fixes: 6b19edcb663c ("build: enable pmdinfogen for Windows")
>
> Signed-off-by: Dmitry Kozlyuk
> Signed-off-by: Thomas Monjalon
Acked-by: Bruce Richardson
One additional suggestion below if you want to take it too.
> ---
> doc/guides/rel_notes/release_21_02.rst | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_21_02.rst
> b/doc/guides/rel_notes/release_21_02.rst
> index 64e220f2ac..99a559479b 100644
> --- a/doc/guides/rel_notes/release_21_02.rst
> +++ b/doc/guides/rel_notes/release_21_02.rst
> @@ -20,6 +20,12 @@ DPDK Release 21.02
>make doc-guides-html
>xdg-open build/doc/html/guides/rel_notes/release_21_02.html
>
> +.. note::
> +
> + A dependency has been added for building DPDK on Linux or FreeBSD:
> + the Python module pyelftools (version 0.22 or greater),
> + often packaged as python3-pyelftools, is required.
This module can also be installed using pip for python3 e.g.
"pip3 install pyelftools".
> +
>
> New Features
>
> @@ -180,6 +186,13 @@ New Features
>tests and output graphed results to PDF files.
>See the :doc:`../tools/cryptoperf` guide for more details.
>
> +* **Added Windows support to pmdinfogen.**
> +
> + PMD information strings were added for Windows as well as for other OS.
> + Extracting them from Windows DLL is not yet supported.
> + The build-time tool pmdinfogen was rewritten in Python,
> + thus libelf dependency was replaced with pyelftools as new build
> dependency.
> +
> * **Added support for build-time checking of header includes.**
>
>A new build option ``check_includes`` has been added, which, when enabled,
> --
> 2.30.0
>
Re: [dpdk-dev] [PATCH v2] doc: add pmdinfogen rewrite to release notes
On 12/02/2021 14:29, Bruce Richardson wrote:
> On Fri, Feb 12, 2021 at 03:17:39PM +0100, Thomas Monjalon wrote:
>> From: Dmitry Kozlyuk
>>
>> The build tool pmdinfogen was rewritten in DPDK 21.02,
>> adding Windows support.
>> There is a new build-time dependency: pyelftools.
>>
>> Fixes: f0f93a7adfee ("buildtools: use Python pmdinfogen")
>> Fixes: 6b19edcb663c ("build: enable pmdinfogen for Windows")
>>
>> Signed-off-by: Dmitry Kozlyuk
>> Signed-off-by: Thomas Monjalon
>
> Acked-by: Bruce Richardson
>
> One additional suggestion below if you want to take it too.
>
>> ---
>> doc/guides/rel_notes/release_21_02.rst | 13 +
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/doc/guides/rel_notes/release_21_02.rst
>> b/doc/guides/rel_notes/release_21_02.rst
>> index 64e220f2ac..99a559479b 100644
>> --- a/doc/guides/rel_notes/release_21_02.rst
>> +++ b/doc/guides/rel_notes/release_21_02.rst
>> @@ -20,6 +20,12 @@ DPDK Release 21.02
>>make doc-guides-html
>>xdg-open build/doc/html/guides/rel_notes/release_21_02.html
>>
>> +.. note::
>> +
>> + A dependency has been added for building DPDK on Linux or FreeBSD:
>> + the Python module pyelftools (version 0.22 or greater),
>> + often packaged as python3-pyelftools, is required.
> This module can also be installed using pip for python3 e.g.
> "pip3 install pyelftools".
>
yep, just about to send a doc patch for that.
>> +
>>
>> New Features
>>
>> @@ -180,6 +186,13 @@ New Features
>>tests and output graphed results to PDF files.
>>See the :doc:`../tools/cryptoperf` guide for more details.
>>
>> +* **Added Windows support to pmdinfogen.**
>> +
>> + PMD information strings were added for Windows as well as for other OS.
>> + Extracting them from Windows DLL is not yet supported.
>> + The build-time tool pmdinfogen was rewritten in Python,
>> + thus libelf dependency was replaced with pyelftools as new build
>> dependency.
>> +
>> * **Added support for build-time checking of header includes.**
>>
>>A new build option ``check_includes`` has been added, which, when enabled,
>> --
>> 2.30.0
>>
>
[dpdk-dev] [PATCH] doc: update info for pyelftools install
python-pyelftools is not packaged for RHEL/CentOS with
the exception of RHEL7 EPEL.
Add command to install it with pip.
Fixes: f0f93a7adfee ("buildtools: use Python pmdinfogen")
Signed-off-by: Kevin Traynor
---
doc/guides/linux_gsg/sys_reqs.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/guides/linux_gsg/sys_reqs.rst
b/doc/guides/linux_gsg/sys_reqs.rst
index 4a401210d..d7ea8520e 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -55,5 +55,7 @@ Compilation of the DPDK
* ``pyelftools`` (version 0.22+)
-* For RHEL/Fedora systems it can be installed using ``dnf install
python-pyelftools``
+* For Fedora systems it can be installed using ``dnf install
python-pyelftools``
+
+* For RHEL/CentOS systems it can be installed using ``pip3 install
pyelftools``
* For Ubuntu/Debian it can be installed using ``apt install
python3-pyelftools``
--
2.26.2
Re: [dpdk-dev] [PATCH] doc: update info for pyelftools install
On Fri, Feb 12, 2021 at 02:46:28PM +, Kevin Traynor wrote:
> python-pyelftools is not packaged for RHEL/CentOS with
> the exception of RHEL7 EPEL.
>
> Add command to install it with pip.
>
> Fixes: f0f93a7adfee ("buildtools: use Python pmdinfogen")
>
> Signed-off-by: Kevin Traynor
> ---
> doc/guides/linux_gsg/sys_reqs.rst | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/linux_gsg/sys_reqs.rst
> b/doc/guides/linux_gsg/sys_reqs.rst
> index 4a401210d..d7ea8520e 100644
> --- a/doc/guides/linux_gsg/sys_reqs.rst
> +++ b/doc/guides/linux_gsg/sys_reqs.rst
> @@ -55,5 +55,7 @@ Compilation of the DPDK
> * ``pyelftools`` (version 0.22+)
>
> -* For RHEL/Fedora systems it can be installed using ``dnf install
> python-pyelftools``
> +* For Fedora systems it can be installed using ``dnf install
> python-pyelftools``
> +
> +* For RHEL/CentOS systems it can be installed using ``pip3 install
> pyelftools``
>
> * For Ubuntu/Debian it can be installed using ``apt install
> python3-pyelftools``
> --
Acked-by: Bruce Richardson
[dpdk-dev] [PATCH 19.11] net/mlx5: fix storing the synched MAC to internal table
From: Souvik Dey
[ upstream commit 493f0bb51c1144eedcff2bba199cab1b64ff9fd0 ]
As the internal MAC table is divided into Unicast and Multicast address
sections, we should check the type of synched MAC address before storing
it to the internal table. Currently the check is not done, and the
synched MAC of 33:33:00:00:00:01 gets stored in the unicast section
(mostly index 1) causing all subsequent mlx5_set_mc_addr_list()
to fail with error -EADDRINUSE, as the mac_list contains the MAC
33:33:00:00:00:01. This denies adding of any new multicast address to
the internal list and also fails to add the MAC address to the device
in case of SR-IOV VF.
Fixes: f22442cb5d42 ("net/mlx5: reduce Netlink commands dependencies")
Fixes: ccdcba53a3f4 ("net/mlx5: use Netlink to add/remove MAC addresses")
Signed-off-by: Souvik Dey
---
drivers/net/mlx5/mlx5_nl.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_nl.c b/drivers/net/mlx5/mlx5_nl.c
index 64580b9..add756d 100644
--- a/drivers/net/mlx5/mlx5_nl.c
+++ b/drivers/net/mlx5/mlx5_nl.c
@@ -678,11 +678,22 @@ mlx5_nl_mac_addr_sync(struct rte_eth_dev *dev)
break;
if (j != MLX5_MAX_MAC_ADDRESSES)
continue;
- /* Find the first entry available. */
- for (j = 0; j != MLX5_MAX_MAC_ADDRESSES; ++j) {
- if (rte_is_zero_ether_addr(&dev->data->mac_addrs[j])) {
- dev->data->mac_addrs[j] = macs[i];
- break;
+ if (rte_is_multicast_ether_addr(&macs[i])) {
+ /* Find the first entry available. */
+ for (j = MLX5_MAX_UC_MAC_ADDRESSES;
+j != MLX5_MAX_MAC_ADDRESSES; ++j) {
+ if (rte_is_zero_ether_addr(&mac_addrs[j])) {
+ mac_addrs[j] = macs[i];
+ break;
+ }
+ }
+ } else {
+ /* Find the first entry available. */
+ for (j = 0; j != MLX5_MAX_UC_MAC_ADDRESSES; ++j) {
+ if (rte_is_zero_ether_addr(&mac_addrs[j])) {
+ mac_addrs[j] = macs[i];
+ break;
+ }
}
}
}
--
2.9.3.windows.1
Notice: This e-mail together with any attachments may contain information of
Ribbon Communications Inc. and its Affiliates that is confidential and/or
proprietary for the sole use of the intended recipient. Any review, disclosure,
reliance or distribution by others or forwarding without express permission is
strictly prohibited. If you are not the intended recipient, please notify the
sender immediately and then delete all copies, including any attachments.
[dpdk-dev] [PATCH v3] doc: add pmdinfogen rewrite to release notes
From: Dmitry Kozlyuk
The build tool pmdinfogen was rewritten in DPDK 21.02,
adding Windows support.
There is a new build-time dependency: pyelftools.
Fixes: f0f93a7adfee ("buildtools: use Python pmdinfogen")
Fixes: 6b19edcb663c ("build: enable pmdinfogen for Windows")
Signed-off-by: Dmitry Kozlyuk
Signed-off-by: Thomas Monjalon
Acked-by: Bruce Richardson
---
doc/guides/rel_notes/release_21_02.rst | 17 +
1 file changed, 17 insertions(+)
diff --git a/doc/guides/rel_notes/release_21_02.rst
b/doc/guides/rel_notes/release_21_02.rst
index 64e220f2ac..743f1505ef 100644
--- a/doc/guides/rel_notes/release_21_02.rst
+++ b/doc/guides/rel_notes/release_21_02.rst
@@ -20,6 +20,16 @@ DPDK Release 21.02
make doc-guides-html
xdg-open build/doc/html/guides/rel_notes/release_21_02.html
+.. note::
+
+ A **dependency** has been added for building DPDK on Linux or FreeBSD:
+ the Python module **pyelftools** (version **0.22** or greater),
+ often packaged as python3-pyelftools, is required.
+
+ If not available as a distribution package, it can be installed with::
+
+ pip3 install pyelftools
+
New Features
@@ -180,6 +190,13 @@ New Features
tests and output graphed results to PDF files.
See the :doc:`../tools/cryptoperf` guide for more details.
+* **Added Windows support to pmdinfogen.**
+
+ PMD information strings were added for Windows as well as for other OS.
+ Extracting them from Windows DLL is not yet supported.
+ The build-time tool pmdinfogen was rewritten in Python,
+ thus libelf dependency was replaced with pyelftools as new build dependency.
+
* **Added support for build-time checking of header includes.**
A new build option ``check_includes`` has been added, which, when enabled,
--
2.30.0
Re: [dpdk-dev] [PATCH 21.05 v2] app/testpmd: support show Rx queue desc count
On 2/12/2021 2:56 PM, Lance Richardson wrote: Add support for querying the count of ready descriptors on a receive queue in order to allow the rte_eth_dev rx_queue_count() API to be exercised and tested. Overall looks good to me, but there are slightly different reference to the feature, the commit title mentions from feature as "show Rx queue desc count", the commit log has as "count of ready descriptors", and the documentation has "rxq desc used count", what do you think unifying them? Signed-off-by: Lance Richardson <...> + .f = cmd_show_rx_queue_desc_used_count_parsed, + .data = NULL, + .help_str = "show port rxq desc used count", Can you please add the new command to the help, 'cmd_help_long_parsed()' too?
[dpdk-dev] [PATCH v3 1/3] service: add component useful work attribute
This commit adds a new attribute which allows the service to indicate
if the previous iteration of work was "useful". Useful work here implies
forward progress was made.
Exposing this information via an attribute to the application allows
tracking of CPU cycles as being useful or not-useful, and a CPU load
estimate can be deduced from that information.
Signed-off-by: Harry van Haaren
---
lib/librte_eal/common/rte_service.c | 19 +++
lib/librte_eal/include/rte_service.h | 5 +
.../include/rte_service_component.h | 13 +
lib/librte_eal/version.map| 3 +++
4 files changed, 40 insertions(+)
diff --git a/lib/librte_eal/common/rte_service.c
b/lib/librte_eal/common/rte_service.c
index bd8fb72e78..859fc3 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -58,6 +58,7 @@ struct rte_service_spec_impl {
uint32_t num_mapped_cores;
uint64_t calls;
uint64_t cycles_spent;
+ uint8_t useful_work_last_iter;
} __rte_cache_aligned;
/* the internal values of a service core */
@@ -294,6 +295,21 @@ rte_service_component_unregister(uint32_t id)
return 0;
}
+int32_t
+rte_service_component_attr_set(uint32_t id, uint32_t attr, uint64_t value)
+{
+ struct rte_service_spec_impl *s;
+ SERVICE_VALID_GET_OR_ERR_RET(id, s, -EINVAL);
+
+ switch (attr) {
+ case RTE_SERVICE_ATTR_USEFUL_WORK_LAST_ITER:
+ s->useful_work_last_iter = value;
+ return 0;
+ default:
+ return -EINVAL;
+ };
+}
+
int32_t
rte_service_component_runstate_set(uint32_t id, uint32_t runstate)
{
@@ -799,6 +815,9 @@ rte_service_attr_get(uint32_t id, uint32_t attr_id,
uint64_t *attr_value)
return -EINVAL;
switch (attr_id) {
+ case RTE_SERVICE_ATTR_USEFUL_WORK_LAST_ITER:
+ *attr_value = s->useful_work_last_iter;
+ return 0;
case RTE_SERVICE_ATTR_CYCLES:
*attr_value = s->cycles_spent;
return 0;
diff --git a/lib/librte_eal/include/rte_service.h
b/lib/librte_eal/include/rte_service.h
index ca9950d091..d50b5c8d7a 100644
--- a/lib/librte_eal/include/rte_service.h
+++ b/lib/librte_eal/include/rte_service.h
@@ -390,6 +390,11 @@ int32_t rte_service_dump(FILE *f, uint32_t id);
*/
#define RTE_SERVICE_ATTR_CALL_COUNT 1
+/**
+ * Returns if the last iteration of the service resulted in useful work done.
+ */
+#define RTE_SERVICE_ATTR_USEFUL_WORK_LAST_ITER 2
+
/**
* Get an attribute from a service.
*
diff --git a/lib/librte_eal/include/rte_service_component.h
b/lib/librte_eal/include/rte_service_component.h
index 9e66ee7e29..534f41f531 100644
--- a/lib/librte_eal/include/rte_service_component.h
+++ b/lib/librte_eal/include/rte_service_component.h
@@ -87,6 +87,19 @@ int32_t rte_service_component_register(const struct
rte_service_spec *spec,
*/
int32_t rte_service_component_unregister(uint32_t id);
+/**
+ * Set an attribute for this service.
+ *
+ * Note this API is to be called by the service implementation, to make the
+ * statistic available via the usual attr_get() service APIs.
+ *
+ * @retval 0 Success
+ * @retval -EINVAL Invalid service id or attribute provided
+ */
+__rte_experimental
+int32_t rte_service_component_attr_set(uint32_t id, uint32_t attr,
+ uint64_t value);
+
/**
* Private function to allow EAL to initialized default mappings.
*
diff --git a/lib/librte_eal/version.map b/lib/librte_eal/version.map
index fce90a112f..e60eaa3dd9 100644
--- a/lib/librte_eal/version.map
+++ b/lib/librte_eal/version.map
@@ -412,6 +412,9 @@ EXPERIMENTAL {
rte_thread_tls_key_delete;
rte_thread_tls_value_get;
rte_thread_tls_value_set;
+
+ # added in 21.05
+ rte_service_component_attr_set;
};
INTERNAL {
--
2.25.1
[dpdk-dev] [PATCH v3 3/3] event/sw: add xstat for work done in last iteration
Today it is difficult to know what Eventdev ports recieved work
from the scheduling core. Sometimes it is useful to know where
work has been scheduled.
This patch implements an xstat for the SW PMD, which provides a
bitmask of ports that were scheduled to. If the SW PMD instance
has more than 64 ports, always report that a port got an event.
Signed-off-by: Harry van Haaren
---
Note most of the changes here are unit-test changes to add
a statistic to the PMD. The actual "useful code" is a mere
handful of lines in a lot of noise.. could split into 2 patches?
---
drivers/event/sw/sw_evdev.h | 1 +
drivers/event/sw/sw_evdev_scheduler.c | 12
drivers/event/sw/sw_evdev_selftest.c | 27 ++-
drivers/event/sw/sw_evdev_xstats.c| 6 +-
4 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/drivers/event/sw/sw_evdev.h b/drivers/event/sw/sw_evdev.h
index 5ab6465c83..5dfa4508b3 100644
--- a/drivers/event/sw/sw_evdev.h
+++ b/drivers/event/sw/sw_evdev.h
@@ -259,6 +259,7 @@ struct sw_evdev {
uint64_t sched_no_iq_enqueues;
uint64_t sched_no_cq_enqueues;
uint64_t sched_cq_qid_called;
+ uint64_t sched_last_iter_bitmask;
uint8_t started;
uint32_t credit_update_quanta;
diff --git a/drivers/event/sw/sw_evdev_scheduler.c
b/drivers/event/sw/sw_evdev_scheduler.c
index c78f687446..3ee1188be0 100644
--- a/drivers/event/sw/sw_evdev_scheduler.c
+++ b/drivers/event/sw/sw_evdev_scheduler.c
@@ -566,6 +566,8 @@ sw_event_schedule(struct rte_eventdev *dev)
rte_service_component_attr_set(sw->service_id,
RTE_SERVICE_ATTR_USEFUL_WORK_LAST_ITER, work_done);
+ uint64_t cqs_scheds_last_iter = 0;
+
/* push all the internal buffered QEs in port->cq_ring to the
* worker cores: aka, do the ring transfers batched.
*/
@@ -585,6 +587,7 @@ sw_event_schedule(struct rte_eventdev *dev)
&sw->cq_ring_space[i]);
port->cq_buf_count = 0;
no_enq = 0;
+ cqs_scheds_last_iter |= (1ULL << i);
} else {
sw->cq_ring_space[i] =
rte_event_ring_free_count(worker) -
@@ -604,4 +607,13 @@ sw_event_schedule(struct rte_eventdev *dev)
sw->sched_min_burst = sw->sched_min_burst_size;
}
+ /* Provide stats on what eventdev ports were scheduled to this
+* iteration. If more than 64 ports are active, always report that
+* all Eventdev ports have been scheduled events.
+*/
+ if (likely(sw->port_count < 64)) {
+ sw->sched_last_iter_bitmask = cqs_scheds_last_iter;
+ } else {
+ sw->sched_last_iter_bitmask = UINT64_MAX;
+ }
}
diff --git a/drivers/event/sw/sw_evdev_selftest.c
b/drivers/event/sw/sw_evdev_selftest.c
index e4bfb3a0f1..7dd35cb22e 100644
--- a/drivers/event/sw/sw_evdev_selftest.c
+++ b/drivers/event/sw/sw_evdev_selftest.c
@@ -873,15 +873,15 @@ xstats_tests(struct test *t)
int ret = rte_event_dev_xstats_names_get(evdev,
RTE_EVENT_DEV_XSTATS_DEVICE,
0, xstats_names, ids, XSTATS_MAX);
- if (ret != 6) {
- printf("%d: expected 6 stats, got return %d\n", __LINE__, ret);
+ if (ret != 7) {
+ printf("%d: expected 7 stats, got return %d\n", __LINE__, ret);
return -1;
}
ret = rte_event_dev_xstats_get(evdev,
RTE_EVENT_DEV_XSTATS_DEVICE,
0, ids, values, ret);
- if (ret != 6) {
- printf("%d: expected 6 stats, got return %d\n", __LINE__, ret);
+ if (ret != 7) {
+ printf("%d: expected 7 stats, got return %d\n", __LINE__, ret);
return -1;
}
@@ -959,7 +959,7 @@ xstats_tests(struct test *t)
ret = rte_event_dev_xstats_get(evdev,
RTE_EVENT_DEV_XSTATS_DEVICE,
0, ids, values, num_stats);
- static const uint64_t expected[] = {3, 3, 0, 1, 0, 0};
+ static const uint64_t expected[] = {3, 3, 0, 1, 0, 0, 4};
for (i = 0; (signed int)i < ret; i++) {
if (expected[i] != values[i]) {
printf(
@@ -975,7 +975,7 @@ xstats_tests(struct test *t)
0, NULL, 0);
/* ensure reset statistics are zero-ed */
- static const uint64_t expected_zero[] = {0, 0, 0, 0, 0, 0};
+ static const uint64_t expected_zero[] = {0, 0, 0, 0, 0, 0, 0};
ret = rte_event_dev_xstats_get(evdev,
RTE_EVENT_DEV_XSTATS_DEVICE,
0, ids, values, num_stats);
@@ -1460,7 +1460,7 @@ xstats
[dpdk-dev] [PATCH v3 2/3] event/sw: add useful work done attribute
This commit exposes if useful work is done to the service instance. The normal service_attr_get() API can be used to retrieve the value of the attribute. Signed-off-by: Harry van Haaren --- drivers/event/sw/sw_evdev_scheduler.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/event/sw/sw_evdev_scheduler.c b/drivers/event/sw/sw_evdev_scheduler.c index f747b3c6d4..c78f687446 100644 --- a/drivers/event/sw/sw_evdev_scheduler.c +++ b/drivers/event/sw/sw_evdev_scheduler.c @@ -5,6 +5,9 @@ #include #include #include + +#include + #include "sw_evdev.h" #include "iq_chunk.h" #include "event_ring.h" @@ -559,6 +562,10 @@ sw_event_schedule(struct rte_eventdev *dev) sw->sched_no_iq_enqueues += (in_pkts_total == 0); sw->sched_no_cq_enqueues += (out_pkts_total == 0); + uint64_t work_done = (in_pkts_total + out_pkts_total) != 0; + rte_service_component_attr_set(sw->service_id, + RTE_SERVICE_ATTR_USEFUL_WORK_LAST_ITER, work_done); + /* push all the internal buffered QEs in port->cq_ring to the * worker cores: aka, do the ring transfers batched. */ -- 2.25.1
Re: [dpdk-dev] [dpdklab] Re: [dpdk-ci] [CI] SPDK compilation failures @ DPDK community lab
Hi Tomek, I do not think we have a specific reason for disabling vhost. I can look into enabling it and get back to you on that. Thanks, Brandon On Fri, Feb 12, 2021 at 4:18 AM Zawadzki, Tomasz wrote: > > Hi, > > As Aaron noted this was result of rte_ethdev depending on rte_net. > On SPDK side rte_net was included in default compilation with vhost > component, but since vhost is disabled in the UNH lab tests with SPDK it > showed up as missing. A fix for that is now submitted to SPDK: > https://review.spdk.io/gerrit/c/spdk/spdk/+/6398 > I'll let you know when it makes it's way to the v21.01.x branch. > > @Brandon Lo General question, is there particular reason to disable vhost > [configure argument '--without-vhost'] in the UNH lab tests with SPDK ? > I don't recall any identified issue and enabling it would increase the > coverage of the compilation tests. > > Thanks, > Tomek > > > -Original Message- > > From: Aaron Conole > > Sent: Thursday, February 11, 2021 3:02 PM > > To: Brandon Lo > > Cc: Zawadzki, Tomasz ; Lincoln Lavoie > > ; dpdk...@iol.unh.edu; c...@dpdk.org; dev@dpdk.org; > > s...@lists.01.org > > Subject: Re: [dpdklab] Re: [dpdk-ci] [dpdk-dev] [CI] SPDK compilation > > failures > > @ DPDK community lab > > > > Brandon Lo writes: > > > > > Hi again everyone, > > > > > > I have checked the pipelines with SPDK branch v21.01.x on the main DPDK > > branch. > > > It still seems to have an issue with compilation, and I have attached > > > a log of a Fedora SPDK compilation. > > > There are some undefined references to "rte_ether_unformat_addr" > > > I will continue to look into this. If you have any ideas on how to fix > > > this, please let me know. > > > > Looks like rte_ethdev depends on rte_net - maybe I missed something. > > > > Brandon, can we disable this test for the time being since it's been > > failing for > > a while now? Can you also send me the container image / definitions you're > > using so that I can help work on this? > > > > > Thanks, > > > Brandon > > > > > > On Tue, Feb 9, 2021 at 11:07 AM Brandon Lo wrote: > > >> > > >> Hi everyone, > > >> > > >> I will adjust the branches and watch over the first few pipelines to > > >> make sure everything goes smoothly. > > >> > > >> Thanks for the update, > > >> Brandon > > >> > > >> On Tue, Feb 9, 2021 at 10:13 AM Aaron Conole > > wrote: > > >> > > > >> > "Zawadzki, Tomasz" writes: > > >> > > > >> > > Hi Lincoln, > > >> > > > > >> > > > > >> > > > > >> > > That patch in question is now merged to branch v21.01.x. > > >> > > > > >> > > > >> > Good to know - I do still see a failure in the IOL job (even from a > > >> > few hours ago). I suppose the lab side might need some adjustment, > > too? > > >> > > > >> > > > > >> > > The builds performed for latest SPDK and SPDK LTS, against > > >> > > dpdk-main branch seem to be passing. Would love to hear if this > > >> > > is what you are seeing on your end too. > > >> > > > > >> > > > > >> > > > > >> > > Thanks, > > >> > > > > >> > > Tomek > > >> > > > > >> > > > > >> > > > > >> > > From: Lincoln Lavoie > > >> > > Sent: Monday, February 8, 2021 5:21 PM > > >> > > To: Zawadzki, Tomasz > > >> > > Cc: Aaron Conole ; Brandon Lo > > >> > > ; dpdk...@iol.unh.edu; c...@dpdk.org; > > >> > > dev@dpdk.org; s...@lists.01.org > > >> > > Subject: Re: [dpdk-ci] [dpdk-dev] [CI] SPDK compilation failures > > >> > > @ DPDK community lab > > >> > > > > >> > > > > >> > > > > >> > > Thanks Tomek, > > >> > > > > >> > > > > >> > > > > >> > > Can you let us know when the merge happens and we'll make sure > > >> > > the next set of builds pass or see what the next failure is. :-P > > >> > > > > >> > > > > >> > > > > >> > > Cheers, > > >> > > Lincoln > > >> > > > > >> > > > > >> > > > > >> > > On Mon, Feb 8, 2021 at 11:03 AM Zawadzki, Tomasz > > wrote: > > >> > > > > >> > > Hi Aaron, > > >> > > > > >> > > Thank you for reporting this ! > > >> > > > > >> > > This is an issue with rte_power now depending on rte_ethdev, which > > was resolved on latest SPDK. > > >> > > > > >> > > I believe that UNH lab verifies DPDK patches against SPDK branch > > >> > > for latest release. Which after the very recent SPDK release, > > >> > > would be v21.01.x: > > >> > > https://github.com/spdk/spdk/tree/v21.01.x > > >> > > > > >> > > The fix has been backported to that branch and should be merged > > shortly: > > >> > > https://review.spdk.io/gerrit/c/spdk/spdk/+/6320 > > >> > > > > >> > > Thanks, > > >> > > Tomek > > >> > > > > >> > > > -Original Message- > > >> > > > From: dev On Behalf Of Aaron Conole > > > >> > > Sent: Monday, February 8, 2021 4:21 PM > To: Brandon Lo > > >> > > > Cc: dpdk...@iol.unh.edu; c...@dpdk.org; > > >> > > dev@dpdk.org; s...@lists.01.org > Subject: [dpdk-dev] [CI] SPDK > > >> > > compilation failures @ DPDK community lab > > Greetings, > > > > >> > > I've noticed that recently SPDK compilation in the UNH community > > >> > > lab seems > to be failing, a
[dpdk-dev] [PATCH 21.05 v2] app/testpmd: support show Rx queue desc count
Add support for querying the count of ready descriptors on a
receive queue in order to allow the rte_eth_dev rx_queue_count()
API to be exercised and tested.
Signed-off-by: Lance Richardson
---
app/test-pmd/cmdline.c | 83 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 ++
2 files changed, 90 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 59722d268..821dd3d77 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -16699,6 +16699,88 @@ cmdline_parse_inst_t cmd_show_rx_tx_desc_status = {
},
};
+/* *** display rx queue desc used count *** */
+struct cmd_show_rx_queue_desc_used_count_result {
+ cmdline_fixed_string_t cmd_show;
+ cmdline_fixed_string_t cmd_port;
+ cmdline_fixed_string_t cmd_rxq;
+ cmdline_fixed_string_t cmd_desc;
+ cmdline_fixed_string_t cmd_used;
+ cmdline_fixed_string_t cmd_count;
+ portid_t cmd_pid;
+ portid_t cmd_qid;
+};
+
+static void
+cmd_show_rx_queue_desc_used_count_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_show_rx_queue_desc_used_count_result *res = parsed_result;
+ int rc;
+
+ if (!rte_eth_dev_is_valid_port(res->cmd_pid)) {
+ printf("invalid port id %u\n", res->cmd_pid);
+ return;
+ }
+
+ rc = rte_eth_rx_queue_count(res->cmd_pid, res->cmd_qid);
+ if (rc < 0) {
+ printf("Invalid queueid = %d\n", res->cmd_qid);
+ return;
+ }
+ printf("Used desc count = %d\n", rc);
+}
+
+cmdline_parse_token_string_t cmd_show_rx_queue_desc_used_count_show =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_show, "show");
+cmdline_parse_token_string_t cmd_show_rx_queue_desc_used_count_port =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_port, "port");
+cmdline_parse_token_num_t cmd_show_rx_queue_desc_used_count_pid =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_pid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_show_rx_queue_desc_used_count_rxq =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_rxq, "rxq");
+cmdline_parse_token_num_t cmd_show_rx_queue_desc_used_count_qid =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_show_rx_queue_desc_used_count_desc =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_count, "desc");
+cmdline_parse_token_string_t cmd_show_rx_queue_desc_used_count_used =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_count, "used");
+cmdline_parse_token_string_t cmd_show_rx_queue_desc_used_count_count =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_count, "count");
+cmdline_parse_inst_t cmd_show_rx_queue_count = {
+ .f = cmd_show_rx_queue_desc_used_count_parsed,
+ .data = NULL,
+ .help_str = "show port rxq desc used count",
+ .tokens = {
+ (void *)&cmd_show_rx_queue_desc_used_count_show,
+ (void *)&cmd_show_rx_queue_desc_used_count_port,
+ (void *)&cmd_show_rx_queue_desc_used_count_pid,
+ (void *)&cmd_show_rx_queue_desc_used_count_rxq,
+ (void *)&cmd_show_rx_queue_desc_used_count_qid,
+ (void *)&cmd_show_rx_queue_desc_used_count_desc,
+ (void *)&cmd_show_rx_queue_desc_used_count_used,
+ (void *)&cmd_show_rx_queue_desc_used_count_count,
+ NULL,
+ },
+};
+
/* Common result structure for set port ptypes */
struct cmd_set_port_ptypes_result {
cmdline_fixed_string_t set;
@@ -17098,6 +17180,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_config_tx_metadata_specific,
(cmdline_parse_inst_t *)&cmd_show_tx_metadata,
(cmdline_parse_inst_t *)&cmd_show_rx_tx_desc_status,
+ (cmdline_parse_inst_t *)&cmd_show_rx_queue_count,
(cmdline_parse_inst_t *)&cmd_set_raw,
(cmdline_parse_inst_t *)&cmd_show_set_raw,
(cmdline_parse_inst_t *)&cmd_show_set_raw_all,
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a45910b81..703dead0c 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -266,6 +266,13 @@ Display information for a given port's RX/TX descriptor
status::
testpmd> show port (port_id) (
[dpdk-dev] officially support building driver plugins externally
Hi, Recently installation of driver headers and export of functions was pulled back from being public to private (commit df96fd0d73955bdc7ca3909e772ff2ad903249c6). From a discussion with Thomas Monjalon we understand that it was not the design intent to ever have these headers exposed publicly, but it was allowing us tomaintain the drivers we do implement outside of the normal dpdk tree. We would like to propose that building driver plugins external to the dpdk source tree be officially supported / restored and it is is our understanding there there are asks from other DPDK consumers for the same. We understand the main concern is that it might incorrectly convey that the API/ABI of the driver interface is stable or promised to be compatible when no such promise exists. Can the broader community help us with an acceptable solution to building the drivers out of the tree? Aside from installing the needed headers what other mechanical things can we do to achieve this? We are happy to do the work/submit the required patches as necessary. Thank you
Re: [dpdk-dev] [PATCH 21.05] app/testpmd: support show Rx queue count
On Fri, Feb 12, 2021 at 6:51 AM Ferruh Yigit wrote: > > On 2/11/2021 7:44 PM, Lance Richardson wrote: > > Add support for querying receive queue count in order to allow > > the rte_eth_dev rx_queue_count() API to be exercised and tested. > > > > +1 to adding this feature, but the naming is a little misleading, "Rx queue > count", it looks like it will print the number of Rx queues, and the API has > the > same problem indeed. > > Can you please clarify it that it is to get number of used descriptor in a Rx > queue? > And "used descriptor" part also needs some explanation I think. > That makes sense, fixed in v2. > > There is already an existing command: > "show port rxq|txq desc status" > > What do you think adding the new one as something like: > "show port rxq desc used count" Sounds good, v2 is updated to use that form. > > +show rxq count > > +~ > > The '~' line length should be same as header length > Fixed in v2. > > + > > +Display the number of ready descriptors on a given RX queue:: > > Can you please describe more, what is "ready descriptor"? > > The 'rte_eth_rx_queue_count()' API should be returning number of descriptors > filled by HW. > I took a stab at this in v2, but maybe it could be expanded more. As I understand it, the returned descriptor count should correspond to the number of packets that could be received in the next call to the burst receive function... not necessarily the hardware-specific notion of a descriptor, which might include descriptors used for chained mbufs, LRO metadata, async status messages from firmware, etc. Thanks, Lance
[dpdk-dev] [PATCH 21.05 v3] app/testpmd: display rxq desc used count
Add support for displaying the count of used (filled by hardware
but not yet processed by the driver) descriptors on a receive
queue in order to allow the rte_eth_dev rx_queue_count() API to
be exercised and tested.
Signed-off-by: Lance Richardson
---
v3:
- Made terminology more consistent betwen commit log, title, and
documentation text.
- Added long help text for new command.
v2:
- Changed command syntax from "show port <> rxq <> count" to
"show port <> rxq <> desc used count".
- Expanded description to clarify the meaning of the displayed
descriptor count.
- Fixed header line length.
app/test-pmd/cmdline.c | 87 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 ++
2 files changed, 94 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 59722d268..8eb2a48ef 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -246,6 +246,10 @@ static void cmd_help_long_parsed(void *parsed_result,
"show port (port_id) rxq|txq (queue_id) desc (desc_id)
status"
" Show status of rx|tx descriptor.\n\n"
+ "show port (port_id) rxq (queue_id) desc used count\n"
+ "Show current number of filled receive"
+ " packet descriptors.\n\n"
+
"show port (port_id) macs|mcast_macs"
" Display list of mac addresses added to
port.\n\n"
@@ -16699,6 +16703,88 @@ cmdline_parse_inst_t cmd_show_rx_tx_desc_status = {
},
};
+/* *** display rx queue desc used count *** */
+struct cmd_show_rx_queue_desc_used_count_result {
+ cmdline_fixed_string_t cmd_show;
+ cmdline_fixed_string_t cmd_port;
+ cmdline_fixed_string_t cmd_rxq;
+ cmdline_fixed_string_t cmd_desc;
+ cmdline_fixed_string_t cmd_used;
+ cmdline_fixed_string_t cmd_count;
+ portid_t cmd_pid;
+ portid_t cmd_qid;
+};
+
+static void
+cmd_show_rx_queue_desc_used_count_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_show_rx_queue_desc_used_count_result *res = parsed_result;
+ int rc;
+
+ if (!rte_eth_dev_is_valid_port(res->cmd_pid)) {
+ printf("invalid port id %u\n", res->cmd_pid);
+ return;
+ }
+
+ rc = rte_eth_rx_queue_count(res->cmd_pid, res->cmd_qid);
+ if (rc < 0) {
+ printf("Invalid queueid = %d\n", res->cmd_qid);
+ return;
+ }
+ printf("Used desc count = %d\n", rc);
+}
+
+cmdline_parse_token_string_t cmd_show_rx_queue_desc_used_count_show =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_show, "show");
+cmdline_parse_token_string_t cmd_show_rx_queue_desc_used_count_port =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_port, "port");
+cmdline_parse_token_num_t cmd_show_rx_queue_desc_used_count_pid =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_pid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_show_rx_queue_desc_used_count_rxq =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_rxq, "rxq");
+cmdline_parse_token_num_t cmd_show_rx_queue_desc_used_count_qid =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_show_rx_queue_desc_used_count_desc =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_count, "desc");
+cmdline_parse_token_string_t cmd_show_rx_queue_desc_used_count_used =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_count, "used");
+cmdline_parse_token_string_t cmd_show_rx_queue_desc_used_count_count =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_queue_desc_used_count_result,
+cmd_count, "count");
+cmdline_parse_inst_t cmd_show_rx_queue_desc_used_count = {
+ .f = cmd_show_rx_queue_desc_used_count_parsed,
+ .data = NULL,
+ .help_str = "show port rxq desc used count",
+ .tokens = {
+ (void *)&cmd_show_rx_queue_desc_used_count_show,
+ (void *)&cmd_show_rx_queue_desc_used_count_port,
+ (void *)&cmd_show_rx_queue_desc_used_count_pid,
+ (void *)&cmd_show_rx_queue_desc_used_count_rxq,
+ (void *)&cmd_show_rx_queue_desc_used_count_qid,
+ (void *)&cmd_show_rx_queue_desc_used_count_desc,
+ (void *)&cmd_show_rx_queue_desc_used_count_used,
+ (void *)&cmd_show
Re: [dpdk-dev] [PATCH] [RFC]: adds support PPS(packet per second) on meter
On Sun, Jan 24, 2021 at 5:02 PM Li Zhang wrote:
> Currently the flow Meter algorithms in rte_flow only supports bytes per
> second(BPS).
> Such as Single Rate Three Color Marker (srTCM rfc2697)
> This RFC adds the packet per second definition in Meter algorithms
> structure,
> to support the rte_mtr APIs with type srTCM pps mode.
>
I thought rfc2697 specified metering using BPS only.
The CIR was measured in bytes per second for IP packets.
Is there a draft or link to the new srTCM mode?
> The below structure will be extended:
> rte_mtr_algorithm
> rte_mtr_meter_profile
> Signed-off-by: Li Zhang
> ---
> lib/librte_ethdev/rte_mtr.h | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
> index 916a09c5c3..6413892aec 100644
> --- a/lib/librte_ethdev/rte_mtr.h
> +++ b/lib/librte_ethdev/rte_mtr.h
> @@ -119,6 +119,9 @@ enum rte_mtr_algorithm {
>
> /** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */
> RTE_MTR_TRTCM_RFC4115,
> +
> + /** Single Rate Three Color Marker (srTCM) in Packet per second
> mode */
> + RTE_MTR_SRTCM_PPS,
> };
>
> /**
> @@ -171,6 +174,18 @@ struct rte_mtr_meter_profile {
> /** Excess Burst Size (EBS) (bytes). */
> uint64_t ebs;
> } trtcm_rfc4115;
> +
> + /** Items only valid when *alg* is set to srTCM - PPS. */
> + struct {
> + /** Committed Information Rate
> (CIR)(packets/second). */
> + uint64_t cir;
> +
> + /** Committed Burst Size (CBS) (bytes). */
> + uint64_t cbs;
> +
> + /** Excess Burst Size (EBS) (bytes). */
> + uint64_t ebs;
> + } srtcm_pps;
> };
> };
>
> @@ -317,6 +332,13 @@ struct rte_mtr_capabilities {
> */
> uint32_t meter_trtcm_rfc4115_n_max;
>
> + /** Maximum number of MTR objects that can have their meter
> configured
> +* to run the srTCM packet per second algorithm. The value of 0
> +* indicates this metering algorithm is not supported.
> +* The maximum value is *n_max*.
> +*/
> + uint32_t meter_srtcm_pps_n_max;
> +
> /** Maximum traffic rate that can be metered by a single MTR
> object. For
> * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC
> 2698,
> * this is the maximum PIR rate. For trTCM RFC 4115, this is the
> maximum
> @@ -342,6 +364,12 @@ struct rte_mtr_capabilities {
> */
> int color_aware_trtcm_rfc4115_supported;
>
> + /**
> + * When non-zero, it indicates that color aware mode is supported
> for
> + * the srTCM packet per second metering algorithm.
> + */
> + int color_aware_srtcm_pps_supported;
> +
> /** When non-zero, it indicates that the policer packet recolor
> actions
> * are supported.
> * @see enum rte_mtr_policer_action
> --
> 2.21.0
>
>
[dpdk-dev] kni interface does not transmit anything
Hello, I've recently migrated from dpdk-18.05 to dpdk-20.11. I built "kni" example according to this tutorial [1], every thing is fine except that it has no output packet (no tx). have I ignored something? I would be grateful if anyone could help me. outputs: > ./BUILD/KNI -L 4-7 -N 4 -- -P -P 0X3 --CONFIG="(0,4,6),(1,5,7)" EAL: Detected 16 lcore(s) EAL: Detected 1 NUMA nodes EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'PA' EAL: No available hugepages reported in hugepages-1048576kB EAL: Probing VFIO support... EAL: VFIO support initialized EAL: using IOMMU type 1 (Type 1) EAL: Probe PCI driver: net_i40e (8086:158b) device: :06:00.0 (socket 0) EAL: Probe PCI driver: net_i40e (8086:158b) device: :06:00.1 (socket 0) EAL: No legacy callbacks, legacy socket not created APP: Initialising port 0 ... APP: Initialising port 1 ... Checking link status done Port 0 Link up at 10 Gbps FDX Autoneg Port 1 Link up at 10 Gbps FDX Autoneg APP: APP: KNI Running APP: kill -SIGUSR1 128701 APP: Show KNI Statistics. APP: kill -SIGUSR2 128701 APP: Zero KNI Statistics. APP: APP: Lcore 5 is reading from port 1 APP: Lcore 6 is writing to port 0 APP: Lcore 7 is writing to port 1 APP: Lcore 4 is reading from port 0 APP: Configure network interface of 0 up KNI: Configure promiscuous mode of 0 to 1 KNI: Configure promiscuous mode of 0 to 0 -- > IFCONFIG VETH0 1.1.2.39/24 UP > TCPDUMP -V -N -I VETH0 07:22:26.218095 IP (tos 0x0, ttl 64, id 15551, offset 0, flags [DF], proto ICMP (1), length 84) 1.1.2.2 > 1.1.2.39: ICMP echo request, id 229, seq 1, length 64 07:22:27.218093 IP (tos 0x0, ttl 64, id 15619, offset 0, flags [DF], proto ICMP (1), length 84) 1.1.2.2 > 1.1.2.39: ICMP echo request, id 229, seq 2, length 64 07:22:28.242082 IP (tos 0x0, ttl 64, id 15826, offset 0, flags [DF], proto ICMP (1), length 84) 1.1.2.2 > 1.1.2.39: ICMP echo request, id 229, seq 3, length 64 07:22:29.266097 IP (tos 0x0, ttl 64, id 15948, offset 0, flags [DF], proto ICMP (1), length 84) 1.1.2.2 > 1.1.2.39: ICMP echo request, id 229, seq 4, length 64 07:22:30.290083 IP (tos 0x0, ttl 64, id 16060, offset 0, flags [DF], proto ICMP (1), length 84) 1.1.2.2 > 1.1.2.39: ICMP echo request, id 229, seq 5, length 64 07:22:31.314073 IP (tos 0x0, ttl 64, id 16118, offset 0, flags [DF], proto ICMP (1), length 84) 1.1.2.2 > 1.1.2.39: ICMP echo request, id 229, seq 6, length 64 07:22:32.342079 IP (tos 0x0, ttl 64, id 16236, offset 0, flags [DF], proto ICMP (1), length 84) 1.1.2.2 > 1.1.2.39: ICMP echo request, id 229, seq 7, length 64 07:22:33.366074 IP (tos 0x0, ttl 64, id 16332, offset 0, flags [DF], proto ICMP (1), length 84) 1.1.2.2 > 1.1.2.39: ICMP echo request, id 229, seq 8, length 64 07:22:34.390079 IP (tos 0x0, ttl 64, id 16511, offset 0, flags [DF], proto ICMP (1), length 84) 1.1.2.2 > 1.1.2.39: ICMP echo request, id 229, seq 9, length 64 -- Best Regards Links: -- [1] https://doc.dpdk.org/guides-20.11/sample_app_ug/kernel_nic_interface.html
