All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gaëtan Rivet" <grive@u256.net>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org, stable@dpdk.org, thomas@monjalon.net
Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v1 2/3] net/ring: fix eth_dev device pointer on allocation
Date: Wed, 6 May 2020 19:32:59 +0200	[thread overview]
Message-ID: <20200506173259.yqulw5omozcw6szz@u256.net> (raw)
In-Reply-To: <e1d133f8-c6b1-4d24-0fa0-053ba46f0315@intel.com>

On 06/05/20 14:43 +0100, Ferruh Yigit wrote:
> On 5/6/2020 1:33 PM, Gaëtan Rivet wrote:
> > On 06/05/20 12:48 +0100, Ferruh Yigit wrote:
> >> On 5/5/2020 8:10 PM, Gaetan Rivet wrote:
> >>> When a net_ring device is allocated, its device pointer is not set
> >>> before calling rte_eth_dev_probing_finish, which is incorrect.
> >>>
> >>> The following:
> >>>   commit: 96cb19521147 ("net/ring: use EAL APIs in PMD specific API")
> >>>   commit: a6992e961050 ("net/ring: set ethernet device field")
> >>>
> >>> already attempted to fix this issue in 17.08, which was fine at the
> >>> time. Adding the hook rte_eth_dev_probing_finish() however created this
> >>> bug, as the eth_dev exposed when this hook is executed is expected to be
> >>> complete.
> >>>
> >>> Remove the prior attempts to fix the issue in rte_pmd_ring_probe() and
> >>> write the pointer properly in do_eth_dev_ring_create().
> >>>
> >>> Cc: stable@dpdk.org
> >>> Fixes: fbe90cdd776c ("ethdev: add probing finish function")
> >>> Cc: ferruh.yigit@intel.com
> >>> Cc: thomas@monjalon.net
> >>> Signed-off-by: Gaetan Rivet <grive@u256.net>
> >>
> >> <...>
> >>
> >>> @@ -325,10 +346,17 @@ do_eth_dev_ring_create(const char *name,
> >>>  	data->kdrv = RTE_KDRV_NONE;
> >>>  	data->numa_node = numa_node;
> >>>  
> >>> -	/* finally assign rx and tx ops */
> >>> +	/* assign rx and tx ops */
> >>>  	eth_dev->rx_pkt_burst = eth_ring_rx;
> >>>  	eth_dev->tx_pkt_burst = eth_ring_tx;
> >>>  
> >>> +	/* finally set the rte_device pointer in eth_dev. */
> >>> +	eth_dev->device = ring_device_from_name(name);
> >>> +	if (eth_dev->device == NULL) {
> >>> +		rte_errno = ENODEV;
> >>> +		goto error;
> >>> +	}
> >>> +
> >>>  	rte_eth_dev_probing_finish(eth_dev);
> >>>  	*eth_dev_p = eth_dev;
> >>
> >> Why not move the 'rte_eth_dev_probing_finish()' to the 'rte_pmd_ring_probe()',
> >> below where 'eth_dev->device' set?
> > 
> > Hi Ferruh,
> > 
> > Sure it would work. The reason I did it this way is two-fold:
> > 
> >   * I disliked having two places where eth_dev->device was conditionally
> >     set. It makes it harder to read rte_pmd_ring_probe.
> 
> Agree, what about using a 'goto' to have the assignment and
> 'rte_eth_dev_probing_finish()' in a single place?
> But check seems needed since creation may failed at that stage, if you think
> better check can be done on 'ret' instead of 'eth_dev'...
> 
> > 
> >   * I was actually thinking, doing this patch, that we should modify
> >     rte_eth_dev_allocate() to take an rte_device as parameter, as all
> >     eth_dev are meant to be backed by an rte_device. Keeping this in
> >     mind, I meant to move writing the pointer closer to the
> >     rte_eth_dev_allocate() call.
> 
> That is a bigger change, may affect many (if not all) PMDs, so I think this can
> be considered when that change is available.
> 
> And although that change may fix the issues that 'eth_dev->device' is not set,
> which we had a few times before, not sure it worth to change all PMDs and ethdev
> API directly couple with rte_device, instead of PMD being the glue. Can be
> discussed more on its own patch.
> 
> > 
> > But you are right that it is needlessly verbose, using
> > vdev_bus->find_device() to do this stuff. I'm ok with changing it as you
> > described if you prefer.
> > 
> 
> That was the concern, that is too much code to take a value which is already
> available a few level up the stack.

Ok, future-proofing is a bad habit so let's not do it.

I'm not a fan of the goto for the 'happy path' though. Another simple
way would be to bring the vdev pointer with me as we go down the stack.

I will send a v2 shortly, if it's too ugly to move the pointer down I'll
use the goto, or if you tell me you'd prefer it.

-- 
Gaëtan

  reply	other threads:[~2020-05-06 17:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27 10:44 [dpdk-dev] [PATCH] net/failsafe: fix fd leak wangyunjian
2020-04-27 11:12 ` Gaëtan Rivet
2020-04-27 16:55   ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2020-05-03 11:33     ` Ali Alnubani
2020-05-04 16:22       ` Gaëtan Rivet
2020-05-04 16:28         ` Stephen Hemminger
2020-05-05  9:47           ` Ali Alnubani
2020-05-05  9:14         ` Ali Alnubani
2020-05-05 18:35           ` Gaëtan Rivet
2020-05-05 19:10       ` [dpdk-dev] [PATCH v1 0/3] failsafe & ring fixes Gaetan Rivet
2020-05-05 19:10         ` [dpdk-dev] [PATCH v1 1/3] net/failsafe: avoid crash on malformed eth_dev Gaetan Rivet
2020-05-06 17:16           ` Ferruh Yigit
2020-05-05 19:10         ` [dpdk-dev] [PATCH v1 2/3] net/ring: fix eth_dev device pointer on allocation Gaetan Rivet
2020-05-06 11:48           ` Ferruh Yigit
2020-05-06 12:33             ` Gaëtan Rivet
2020-05-06 13:43               ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2020-05-06 17:32                 ` Gaëtan Rivet [this message]
2020-05-06 18:09                   ` [dpdk-dev] [PATCH v2] " Gaetan Rivet
2020-05-08 11:00                     ` Ferruh Yigit
2020-05-11 16:54                       ` Ferruh Yigit
2020-05-05 19:10         ` [dpdk-dev] [PATCH v1 3/3] net/failsafe: fix default service proxy state Gaetan Rivet
2020-05-06  8:58           ` Ali Alnubani
2020-05-06 17:16           ` Ferruh Yigit

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=20200506173259.yqulw5omozcw6szz@u256.net \
    --to=grive@u256.net \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.