* [dpdk-dev] 8023ad bond tx crashed if one port has 2 more tx queues
@ 2019-03-19 9:41 hfli
2019-03-19 9:41 ` hfli
2019-03-19 15:05 ` Chas Williams
0 siblings, 2 replies; 4+ messages in thread
From: hfli @ 2019-03-19 9:41 UTC (permalink / raw)
To: declan.doherty, chas3, dev
Hi Guys,
I found a bug in dpdk bond code, while one port has 2 more tx queues, 8023ad
bond port will be crashed in tx burst.
Just analyzed the code below, if 2 more CPU cores send packets on a port by
different tx queue, the arrays like
slave_port_ids/ dist_slave_port_ids/ slave_tx_fail_coun/ slave_bufs will be
shared by all of cores, it will be crashed in this function.
Is there any better solution for this? For now, I just add lock for
rte_eth_tx_burst.
static uint16_t
bond_ethdev_tx_burst_8023ad(void *queue, struct rte_mbuf **bufs,
uint16_t nb_bufs)
{
struct bond_tx_queue *bd_tx_q = (struct bond_tx_queue *)queue;
struct bond_dev_private *internals = bd_tx_q->dev_private;
uint16_t [RTE_MAX_ETHPORTS];
uint16_t slave_count;
uint16_t dist_slave_port_ids[RTE_MAX_ETHPORTS];
uint16_t dist_slave_count;
/* 2-D array to sort mbufs for transmission on each slave into */
struct rte_mbuf *slave_bufs[RTE_MAX_ETHPORTS][nb_bufs];
/* Number of mbufs for transmission on each slave */
uint16_t slave_nb_bufs[RTE_MAX_ETHPORTS] = { 0 };
/* Mapping array generated by hash function to map mbufs to slaves
*/
uint16_t bufs_slave_port_idxs[RTE_MAX_ETHPORTS] = { 0 };
uint16_t slave_tx_count, slave_tx_fail_count[RTE_MAX_ETHPORTS] = {
0 };
uint16_t total_tx_count = 0, total_tx_fail_count = 0;
Thanks and Regards,
Haifeng
^ permalink raw reply [flat|nested] 4+ messages in thread* [dpdk-dev] 8023ad bond tx crashed if one port has 2 more tx queues
2019-03-19 9:41 [dpdk-dev] 8023ad bond tx crashed if one port has 2 more tx queues hfli
@ 2019-03-19 9:41 ` hfli
2019-03-19 15:05 ` Chas Williams
1 sibling, 0 replies; 4+ messages in thread
From: hfli @ 2019-03-19 9:41 UTC (permalink / raw)
To: declan.doherty, chas3, dev
Hi Guys,
I found a bug in dpdk bond code, while one port has 2 more tx queues, 8023ad
bond port will be crashed in tx burst.
Just analyzed the code below, if 2 more CPU cores send packets on a port by
different tx queue, the arrays like
slave_port_ids/ dist_slave_port_ids/ slave_tx_fail_coun/ slave_bufs will be
shared by all of cores, it will be crashed in this function.
Is there any better solution for this? For now, I just add lock for
rte_eth_tx_burst.
static uint16_t
bond_ethdev_tx_burst_8023ad(void *queue, struct rte_mbuf **bufs,
uint16_t nb_bufs)
{
struct bond_tx_queue *bd_tx_q = (struct bond_tx_queue *)queue;
struct bond_dev_private *internals = bd_tx_q->dev_private;
uint16_t [RTE_MAX_ETHPORTS];
uint16_t slave_count;
uint16_t dist_slave_port_ids[RTE_MAX_ETHPORTS];
uint16_t dist_slave_count;
/* 2-D array to sort mbufs for transmission on each slave into */
struct rte_mbuf *slave_bufs[RTE_MAX_ETHPORTS][nb_bufs];
/* Number of mbufs for transmission on each slave */
uint16_t slave_nb_bufs[RTE_MAX_ETHPORTS] = { 0 };
/* Mapping array generated by hash function to map mbufs to slaves
*/
uint16_t bufs_slave_port_idxs[RTE_MAX_ETHPORTS] = { 0 };
uint16_t slave_tx_count, slave_tx_fail_count[RTE_MAX_ETHPORTS] = {
0 };
uint16_t total_tx_count = 0, total_tx_fail_count = 0;
Thanks and Regards,
Haifeng
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [dpdk-dev] 8023ad bond tx crashed if one port has 2 more tx queues
2019-03-19 9:41 [dpdk-dev] 8023ad bond tx crashed if one port has 2 more tx queues hfli
2019-03-19 9:41 ` hfli
@ 2019-03-19 15:05 ` Chas Williams
2019-03-19 15:05 ` Chas Williams
1 sibling, 1 reply; 4+ messages in thread
From: Chas Williams @ 2019-03-19 15:05 UTC (permalink / raw)
To: hfli, declan.doherty, chas3, dev
On 3/19/19 5:41 AM, hfli@netitest.com wrote:
> Hi Guys,
>
> I found a bug in dpdk bond code, while one port has 2 more tx queues,
> 8023ad bond port will be crashed in tx burst.
>
> Just analyzed the code below, if 2 more CPU cores send packets on a port
> by different tx queue, the arrays like
>
> slave_port_ids/ dist_slave_port_ids/ slave_tx_fail_coun/ slave_bufs will
> be shared by all of cores, it will be crashed in this function.
I am afraid that I don't understand this description. I believe that
these are allocated on the stack and shouldn't be shared between
threads.
There isn't any locking currently in the driver. You need to stop the
data path before making changes to the slaves (with the exception of
link status) attached to the bonding device.
> Is there any better solution for this? For now, I just add lock for
> rte_eth_tx_burst.
>
> static uint16_t
>
> bond_ethdev_tx_burst_8023ad(void *queue, struct rte_mbuf **bufs,
> uint16_t nb_bufs)
>
> {
> struct bond_tx_queue *bd_tx_q = (struct bond_tx_queue *)queue;
> struct bond_dev_private *internals = bd_tx_q->dev_private;
> uint16_t slave_port_ids[RTE_MAX_ETHPORTS];
> uint16_t slave_count;
>
> uint16_t dist_slave_port_ids[RTE_MAX_ETHPORTS];
> uint16_t dist_slave_count;
>
> /* 2-D array to sort mbufs for transmission on each slave into */
> struct rte_mbuf *slave_bufs[RTE_MAX_ETHPORTS][nb_bufs];
>
> /* Number of mbufs for transmission on each slave */
> uint16_t slave_nb_bufs[RTE_MAX_ETHPORTS] = { 0 };
>
> /* Mapping array generated by hash function to map mbufs to
> slaves */
> uint16_t bufs_slave_port_idxs[RTE_MAX_ETHPORTS] = { 0 };
> uint16_t slave_tx_count, slave_tx_fail_count[RTE_MAX_ETHPORTS]
> = { 0 };
> uint16_t total_tx_count = 0, total_tx_fail_count = 0;
>
> Thanks and Regards,
>
> Haifeng
>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [dpdk-dev] 8023ad bond tx crashed if one port has 2 more tx queues
2019-03-19 15:05 ` Chas Williams
@ 2019-03-19 15:05 ` Chas Williams
0 siblings, 0 replies; 4+ messages in thread
From: Chas Williams @ 2019-03-19 15:05 UTC (permalink / raw)
To: hfli, declan.doherty, chas3, dev
On 3/19/19 5:41 AM, hfli@netitest.com wrote:
> Hi Guys,
>
> I found a bug in dpdk bond code, while one port has 2 more tx queues,
> 8023ad bond port will be crashed in tx burst.
>
> Just analyzed the code below, if 2 more CPU cores send packets on a port
> by different tx queue, the arrays like
>
> slave_port_ids/ dist_slave_port_ids/ slave_tx_fail_coun/ slave_bufs will
> be shared by all of cores, it will be crashed in this function.
I am afraid that I don't understand this description. I believe that
these are allocated on the stack and shouldn't be shared between
threads.
There isn't any locking currently in the driver. You need to stop the
data path before making changes to the slaves (with the exception of
link status) attached to the bonding device.
> Is there any better solution for this? For now, I just add lock for
> rte_eth_tx_burst.
>
> static uint16_t
>
> bond_ethdev_tx_burst_8023ad(void *queue, struct rte_mbuf **bufs,
> uint16_t nb_bufs)
>
> {
> struct bond_tx_queue *bd_tx_q = (struct bond_tx_queue *)queue;
> struct bond_dev_private *internals = bd_tx_q->dev_private;
> uint16_t slave_port_ids[RTE_MAX_ETHPORTS];
> uint16_t slave_count;
>
> uint16_t dist_slave_port_ids[RTE_MAX_ETHPORTS];
> uint16_t dist_slave_count;
>
> /* 2-D array to sort mbufs for transmission on each slave into */
> struct rte_mbuf *slave_bufs[RTE_MAX_ETHPORTS][nb_bufs];
>
> /* Number of mbufs for transmission on each slave */
> uint16_t slave_nb_bufs[RTE_MAX_ETHPORTS] = { 0 };
>
> /* Mapping array generated by hash function to map mbufs to
> slaves */
> uint16_t bufs_slave_port_idxs[RTE_MAX_ETHPORTS] = { 0 };
> uint16_t slave_tx_count, slave_tx_fail_count[RTE_MAX_ETHPORTS]
> = { 0 };
> uint16_t total_tx_count = 0, total_tx_fail_count = 0;
>
> Thanks and Regards,
>
> Haifeng
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-03-19 15:05 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-19 9:41 [dpdk-dev] 8023ad bond tx crashed if one port has 2 more tx queues hfli
2019-03-19 9:41 ` hfli
2019-03-19 15:05 ` Chas Williams
2019-03-19 15:05 ` Chas Williams
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).