From: Edwin Brossette
rx_buf_size is computed at 2 different places: in qede_rx_queue_setup()
and in qede_set_mtu().
In qede_rx_queue_setup(), it is initialized with mtu + RTE_ETHER_HDR_LEN
and QEDE_ETH_OVERHEAD is added to it in qede_calc_rx_buf_size().
In qede_set_mtu(), it is initialized
From: Edwin Brossette
When the MTU configured is lower than maximum mbuf size (all packet data
can be stored in a single mbuf), then rx buffer size is configured with
MTU + some overhead. A flooring is applied to this value to align it,
meaning its actual value is going to be lower than expected
From: Edwin Brossette
This reverts commit d8ded501e05ce879f27f0ed1df7721a88b737e25.
The maximum length for Rx packets computed in qede_rx_queue_setup()
takes Ethernet CRC into account. This is not consistent with the value
computed in qede_set_mtu(). RTE_ETHER_CRC_LEN should not be added to
From: Edwin Brossette
As per the rte_mbuf API: the driver is responsible of initializing all
the required fields. This is not done at qede alloc, meaning there can
be garbage data in mbufs memory, although this garbage data should be
overwritten when the mbufs are used. Since a sanity check is
: 81f8804992c9 ("net/qede: enhance Rx CPU utilization")
Fixes: 3d4bb4411683 ("net/qede: add fastpath support for VXLAN tunneling")
CC: sta...@dpdk.org
Signed-off-by: Edwin Brossette
Signed-off-by: Didier Pallard
Acked-by: Olivier Matz
---
drivers/net/qede/qede_rxtx.c | 12
Hello,
I have several issues to report concerning the qede pmd as well as
potential solutions for them. Most of them have to do with configuring the
MTU.
== Abort on mtu change ===
First, the qede_assign_rxtx_handlers() seems to be working wrong since an
API change in the rte_eth
Hello,
Thank you for your answer.
The short patch I joined with my first mail was just a rough example to
report what I tested. I believe you know the driver's code better than I
do, so I wouldn't be opposed to see you fix this issue.
Thank you in advance.
Regards,
Edwin Brossette.
O
Hello,
Sorry for bothering you again.
May I inquire if this issue is still being worked on ?
If so, when can I expect to see a fix ?
Best regards,
Edwin Brossette
On Mon, Dec 23, 2024 at 2:09 PM Slava Ovsiienko
wrote:
> Confirm, it’s a bug, IIUC was introduced by reporting function upd
info->tx_desc_lim.nb_max =
+ 1 << priv->sh->cdev->config.hca_attr.log_max_wq_sz;
+ }
if (priv->sh->cdev->config.hca_attr.mem_rq_rmp &&
priv->obj_ops.rxq_obj_new == devx_obj_ops.rxq_obj_new)
info->dev_capa |= RTE_ETH_DEV_CAPA_RXQ_SHARE;
Thanks in advance for your help.
Regards,
Edwin Brossette.
e(), and
is called when the mtu is changed.
I suspect the operations described in comment above might also be needed
when running rte_eth_dev_configure().
Is this a known issue ?
In my application case, this bug causes issues when I need to restart and
configure the port.
Thank you for considering this issue.
Regards,
Edwin Brossette.
Hello,
I created a Bugzilla PR, just as you requested:
https://bugs.dpdk.org/show_bug.cgi?id=1536
As for the bug resolution, I have other matters to attend to and I'm afraid
I cannot spend more time on this issue, so I was only planning to report it.
Regards,
Edwin Brossette.
On Fri,
and if sdev->state
== DEV_PROBED, we call them in the opposite order.
Perhaps someone could look into it?
Regards,
Edwin Brossette.
rks for me:
if (dev->data->nb_tx_queues + dev->data->nb_rx_queues > RTE_MP_MAX_FD_NUM)
return -1;
I've made the changes on my local branch to fix my issue. This mail is just
to bring attention on this problem.
Thank you in advance for considering it.
Regards,
Edwin Brossette.
From: Edwin Brossette
Since link state may need some time to stabilize after a link state
change, we cannot update the link state right after one occurs. So link
state change interrupts (lsc) are handled after a delay. To do this, an
alarm to call a delayed handler is programmed. This delayed
Hello,
I have found a bug in the ixgbe pmd, concerning this model of nic in
particular:
-> Intel Corporation Ethernet Connection X552/X557-AT 10GBASE-T
I was able to detect this bug after enabling the use of Link state change
interrupt in the card via the following flag:
- port->rte_conf
From: Edwin Brossette
Different Intel nics with the igxbe pmd do not handle RSS in the same
way when working with virtualization. While some nics like Intel 82599ES
only have a single RSS table in the device and leave all rss features to
be handled by the pf, some other nics like x550 let the vf
Hello,
We recently ran into an issue with our product when working with an X550
nic with stable dpdk-23.11. We observed that all the incoming traffic was
directed only into a single queue.
The issue became evident after displaying the RSS reta which was fully
zeroed after device init, thus direct
gards,
Edwin Brossette.
From: Edwin Brossette
The flag RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS was temporarily set while
moving queue stats from 'struct rte_eth_stats' to the individual pmds,
as explained in commit f30e69b41f94 ("ethdev: add device flag to bypass
auto-filled queue xstats").
This flag wa
Hello again,
The flag is already set during the device init, so it should be removed,
not added.
I can confirm removing it fixed my issue.
I will submit a patch for this bug.
Regards,
Edwin Brossette.
On Fri, Nov 24, 2023 at 11:39 AM Maxime Coquelin
wrote:
> Hi Edwin,
>
> T
Hello,
I noticed a small inconsistency in the virtio pmd's xstats.
The stat "rx_q0_errors" appears twice.
I also think the stats "rx_q0_packets", "rx_q0_bytes", "tx_q0_packets" and
"tx_q0_bytes" are duplicates of "rx_q0_good_packets", "rx_q0_good_bytes",
"tx_q0_good_packets" and "tx_q0_good_bytes"
ent number of RX queues: 2
> Max possible RX queues: 117
> Max possible number of RXDs per queue: 8192
> Min possible number of RXDs per queue: 16
> RXDs number alignment: 1
> Current number of TX queues: 2
> Max possible TX queues: 117
> Max possible number of TXDs per queue: 4096
> Min possibl
From: Edwin Brossette
When getting the device's info via bnxt_dev_info_get_op(), the device
enables interrupts on link state changes because of the following line:
> eth_dev->data->dev_conf.intr_conf.lsc = 1;
Enabling this mode might not be wanted by the user.
The flag RTE_ET
TUP )
Switch name: :02:00.0
Switch domain Id: 0
Switch Port Id: 32768
Device error handling mode: proactive
This shows link status is seen as up, even although link speed is None.
I was wondering if patching the code to move this line which sets lsc
interrupt on somewhere else might be reasonable, or if this could cause
further trouble. Maybe having a parameter to trigger it ON/OFF might be a
good addition.
May I have your opinion on this matter?
Sincerely,
Edwin Brossette
24 matches
Mail list logo
