DPDK patches and discussions
 help / color / mirror / Atom feed
From: Chas Williams <3chas3@gmail.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	Chas Williams <chas3@att.com>
Cc: dev@dpdk.org, stable@dpdk.org, Declan Doherty <declan.doherty@intel.com>
Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] net/bonding: do not inherit slave device configuration
Date: Sun, 8 Dec 2019 10:44:31 -0500	[thread overview]
Message-ID: <656592a0-bc73-51d0-7ecc-996d027e7d42@gmail.com> (raw)
In-Reply-To: <79c1f419-524c-a4d2-c97f-39789afe4d8a@solarflare.com>



On 2019-11-19 07:40, Andrew Rybchenko wrote:
 > On 11/19/19 3:18 PM, Ferruh Yigit wrote:
 >> On 11/19/2019 9:03 AM, Andrew Rybchenko wrote:
 >>> Bonding device should control bonded devices configuration.
 >>>
 >>> Also avoid usage of slave's data->dev_conf.
 >>>
 >>> Fixes: 2efb58cbab6e ("bond: new link bonding library")
 >>> Cc: stable@dpdk.org
 >>>
 >>> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
 >>> ---
 >>>   drivers/net/bonding/rte_eth_bond_pmd.c | 24 ++++++++++++------------
 >>>   1 file changed, 12 insertions(+), 12 deletions(-)
 >>>
 >>> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c 
b/drivers/net/bonding/rte_eth_bond_pmd.c
 >>> index 707a0f3cdd..4f0e83205d 100644
 >>> --- a/drivers/net/bonding/rte_eth_bond_pmd.c
 >>> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
 >>> @@ -1679,6 +1679,7 @@ int
 >>>   slave_configure(struct rte_eth_dev *bonded_eth_dev,
 >>>   		struct rte_eth_dev *slave_eth_dev)
 >>>   {
 >>> +	struct rte_eth_conf dev_conf;
 >>>   	struct bond_rx_queue *bd_rx_q;
 >>>   	struct bond_tx_queue *bd_tx_q;
 >>>   	uint16_t nb_rx_queues;
 >>> @@ -1693,34 +1694,34 @@ slave_configure(struct rte_eth_dev 
*bonded_eth_dev,
 >>>   	/* Stop slave */
 >>>   	rte_eth_dev_stop(slave_eth_dev->data->port_id);
 >>>
 >>> +	memset(&dev_conf, 0, sizeof(dev_conf));
 >>> +
 >>>   	/* Enable interrupts on slave device if supported */
 >>>   	if (slave_eth_dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC)
 >>> -		slave_eth_dev->data->dev_conf.intr_conf.lsc = 1;
 >>> +		dev_conf.intr_conf.lsc = 1;
 >> I assume the original intention is making incremental changes to the 
existing
 >> slave configuration, if so we should copy the 
'slave_eth_dev->data->dev_conf' to
 >> 'dev_conf' before start updating it.
 >
 > The problem is that I don't understand how incremental changes
 > happen. It simply looks wrong or I don't understand something.
 > It looks like it is the only place in bonding where slave configuration
 > is done.
 >

I understand your confusion. Yes, it certainly looks like
slave_configure() is doing things wrong by directly modifying the slave's
data->dev_conf. If rte_eth_dev_configure() fails, the changes made do
get rolled back and become visible anyway despite the device having
failed to meet that configuration. rte_eth_dev_configure() handles the
rollback, but can't do anything in this case because it doesn't know
the device was directly modified.

You should make a copy of the dev_conf instead of starting from scratch.
There are other capabilities in there that bonding doesn't care about
but the application might.

  parent reply	other threads:[~2019-12-08 15:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-19  9:03 [dpdk-dev] " Andrew Rybchenko
2019-11-19 12:18 ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2019-11-19 12:40   ` Andrew Rybchenko
2019-12-03 10:17     ` Ferruh Yigit
2019-12-08 15:44     ` Chas Williams [this message]
2019-12-09  7:16       ` Andrew Rybchenko
2019-12-09 13:36         ` Chas Williams
2019-12-09 14:31           ` Andrew Rybchenko
2019-12-09 14:45             ` Chas Williams

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=656592a0-bc73-51d0-7ecc-996d027e7d42@gmail.com \
    --to=3chas3@gmail.com \
    --cc=arybchenko@solarflare.com \
    --cc=chas3@att.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=stable@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).