[dpdk-dev] dpdk 0005-net-bonding-reconfigure-all-slave-queues-every-time.patch issue

[dpdk-dev] dpdk 0005-net-bonding-reconfigure-all-slave-queues-every-time.patch issue

[Wen Chiu]

Hi,

0005-net-bonding-reconfigure-all-slave-queues-every-time.patch is now 
officially in dpdk 17.02. But, it caused segmentation fault every time 
when I configured bonding. In slave_configure(), "Setup Tx Queues" logic 
change from for q_id=old_nb_tx_queues to qid=0 which always enters the 
for loop and calls rte_eth_tx_queue_setup. After that, 
rte_eth_dev_start() is called to start the device. In 
rte_eth_dev_start(), vmxnet3_dev_start() is called which calls 
vmxnet3_dev_rxtx_init(). In vmxnet3_dev_rxtx_init(), after for loop for 
rx_queues; dev->data->tx_queues[0] is override with value like 
0x121b20600 which is an invalid memory address that caused the fault.

Without this 0005 patch, looks like rte_eth_tx_queue_setup() is never 
called as q_id=old_nb_tx_queues never < nb_tx_queues. So, I suspect the 
calls to queue_setup() somehow makes the queues to be setup incorrectly 
or incompletely which causes the fault. Has anyone else encounters the 
same issue?

Regards,

Wen Chiu

Re: [dpdk-dev] dpdk 0005-net-bonding-reconfigure-all-slave-queues-every-time.patch issue

[Jan Blunck]

On Thu, Mar 9, 2017 at 3:22 AM, Wen Chiu <wchiu@brocade.com> wrote:
> Hi,
>
> 0005-net-bonding-reconfigure-all-slave-queues-every-time.patch is now
> officially in dpdk 17.02.

This is commit 1e2eff64f554 ("net/bonding: reconfigure all slave
queues every time").

> But, it caused segmentation fault every time when
> I configured bonding. In slave_configure(), "Setup Tx Queues" logic change
> from for q_id=old_nb_tx_queues to qid=0 which always enters the for loop and
> calls rte_eth_tx_queue_setup. After that, rte_eth_dev_start() is called to
> start the device. In rte_eth_dev_start(), vmxnet3_dev_start() is called
> which calls vmxnet3_dev_rxtx_init(). In vmxnet3_dev_rxtx_init(), after for
> loop for rx_queues; dev->data->tx_queues[0] is override with value like
> 0x121b20600 which is an invalid memory address that caused the fault.
>
> Without this 0005 patch, looks like rte_eth_tx_queue_setup() is never called
> as q_id=old_nb_tx_queues never < nb_tx_queues. So, I suspect the calls to
> queue_setup() somehow makes the queues to be setup incorrectly or
> incompletely which causes the fault.

So did the slave_configure() actually return an error?

> Has anyone else encounters the same
> issue?

No, not with the device I tested with.

> Regards,
>
> Wen Chiu
>
>
>