From: Miao Yan <yanmiaobest@gmail.com>
To: users@dpdk.org
Subject: [dpdk-users] Possible race in bonding driver ?
Date: Mon, 17 Dec 2018 17:12:01 +0800 [thread overview]
Message-ID: <CAPc5xaP3YLvhiNWKBkvz_ePnWJGkK05OUOEwPNRnWh1d9q4DHQ@mail.gmail.com> (raw)
Hello Experts,
I am currently working on a project to implement a new team policy
based on the bonding driver. Basically, I have lots of 'ports', each of them
has a ID. I'd like to use the ID to calculate the hash and distribute
the traffic to different slave ports, similar to round-robin, except
the sender ID
is fixed.
And when looking into bonding driver code, the following code looks like racy:
static uint16_t
bond_ethdev_tx_burst_round_robin(void *queue, struct rte_mbuf **bufs,
uint16_t nb_pkts)
{
...
/* Copy slave list to protect against slave up/down changes during tx
* bursting */
num_of_slaves = internals->active_slave_count;
memcpy(slaves, internals->active_slaves,
sizeof(internals->active_slaves[0]) * num_of_slaves);
[...]
}
void
deactivate_slave(struct rte_eth_dev *eth_dev, uint16_t port_id)
{
[...]
/* If slave was not at the end of the list
* shift active slaves up active array list */
if (slave_pos < active_count) {
active_count--;
memmove(internals->active_slaves + slave_pos,
internals->active_slaves + slave_pos + 1,
(active_count - slave_pos) *
sizeof(internals->active_slaves[0]));
}
[...]
}
What if a core is dumping packets to the bond device and at the same time
a slave is down and another core is handling the deactivation (or it
could be just
another core calling rte_bond_slave_remove). It seems it's possible
for the TX core to see a partially updated active_slaves array during memmove.
Is this a problem or am I missing something ? Thank you for the help.
Regards,
Miao
reply other threads:[~2018-12-17 9:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPc5xaP3YLvhiNWKBkvz_ePnWJGkK05OUOEwPNRnWh1d9q4DHQ@mail.gmail.com \
--to=yanmiaobest@gmail.com \
--cc=users@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).