All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Kerlin, MarcinX" <marcinx.kerlin@intel.com>
Cc: dev@dpdk.org, "De Lara Guarch,
	Pablo" <pablo.de.lara.guarch@intel.com>,
	"Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>
Subject: Re: [PATCH v5 1/2] librte_ether: add protection against overwrite device data
Date: Thu, 06 Oct 2016 16:20:47 +0200	[thread overview]
Message-ID: <1556703.BdlfNHUksg@xps13> (raw)
In-Reply-To: <68D830D942438745AD09BAFA99E33E812BE4BC@IRSMSX102.ger.corp.intel.com>

2016-10-06 13:57, Kerlin, MarcinX:
> Hi Thomas,
> 
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 
> > Hi Marcin,
> > 
> > 2016-09-30 16:00, Marcin Kerlin:
> > > Added protection against overwrite device data in array
> > > rte_eth_dev_data[] for the next secondary applications. Secondary
> > > process appends in the first free place rather than at the beginning.
> > > This behavior prevents overwriting devices data of primary process by
> > secondary process.
> > 
> > I've just realized that you are trying to fix an useless code.
> > Why not just remove the array rte_eth_dev_data[] at first?
> 
> because pointer to rte_eth_dev_data in rte_eth_devices[] is 
> just to array rte_eth_dev_data[].
> 
> rte_ethdev.c:214 
> eth_dev->data = &rte_eth_dev_data[port_id];

This line indicates that the pointer data is to the struct rte_eth_dev_data
of the port_id, not the array of every devices.

> > We already have the array rte_eth_devices[] and there is a pointer to
> > rte_eth_dev_data in rte_eth_dev.
> 
> As you write above there is a pointer, but after run secondary testpmd this pointer
> will indicate data which hold from now data for secondary testpmd.
[...]
I think I've understood the bug.
I'm just saying you are fixing a weird design (rte_eth_dev_data[]).

> > Is it just a workaround to be able to lookup the rte_eth_dev_data memzone in
> > the secondary process?
> 
> No it is not workaround, it is protection against overwrite device data.
> I think that my cover letter good explain what is wrong. I did there
> short debug log.

I'm talking about the initial introduction of rte_eth_dev_data[]
which seems to be a workaround for multi-process without touching
rte_eth_devices[] allocated as a global variable (not a memzone).

> > So wouldn't it be saner to have rte_eth_devices[] in a memzone?
> 
> So you mean that move rte_eth_devices[] to memzone + remove rte_eth_dev_data[].

Yes

> What will indicate pointer inside rte_eth_dev  rte_eth_devices[]:
> (struct rte_eth_dev_data *data;  /**< Pointer to device data */)

After thinking more about it, I realize that rte_eth_devices cannot be
in a shared memzone because of its local pointers.

Sorry for the noise, I'll reconsider your patch.

  reply	other threads:[~2016-10-06 14:20 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-02  8:58 [PATCH 0/2] app/testpmd: improve multiprocess support Marcin Kerlin
2016-09-02  8:58 ` [PATCH 1/2] librte_ether: ensure not overwrite device data in mp app Marcin Kerlin
2016-09-11 12:23   ` Yuanhan Liu
2016-09-20 14:06   ` [PATCH v2 0/2] app/testpmd: improve multiprocess support Marcin Kerlin
2016-09-20 14:31   ` Marcin Kerlin
2016-09-20 14:31     ` [PATCH v2 1/2] librte_ether: ensure not overwrite device data in mp app Marcin Kerlin
2016-09-20 16:14       ` Pattan, Reshma
2016-09-22 14:11         ` Kerlin, MarcinX
2016-09-23 14:12           ` Thomas Monjalon
2016-09-26 15:07             ` Kerlin, MarcinX
2016-09-20 16:48       ` Pattan, Reshma
2016-09-22 14:21         ` Kerlin, MarcinX
2016-09-26 14:53       ` [PATCH v3 0/2] app/testpmd: improve multiprocess support Marcin Kerlin
2016-09-26 14:53         ` [PATCH v3 1/2] librte_ether: ensure not overwrite device data in mp app Marcin Kerlin
2016-09-27  3:06           ` Yuanhan Liu
2016-09-27 10:01             ` Kerlin, MarcinX
2016-09-27 10:29           ` [PATCH v4 0/2] app/testpmd: improve multiprocess support Marcin Kerlin
2016-09-27 11:13           ` Marcin Kerlin
2016-09-27 11:13             ` [PATCH v4 1/2] librte_ether: add protection against overwrite device data Marcin Kerlin
2016-09-28 11:00               ` Pattan, Reshma
2016-09-28 14:03               ` Pattan, Reshma
2016-09-29 13:41                 ` Kerlin, MarcinX
2016-09-30 14:00               ` [PATCH v5 0/2] app/testpmd: improve multiprocess support Marcin Kerlin
2016-09-30 14:00                 ` [PATCH v5 1/2] librte_ether: add protection against overwrite device data Marcin Kerlin
2016-09-30 15:00                   ` Pattan, Reshma
2016-10-06  9:41                   ` Thomas Monjalon
2016-10-06 13:57                     ` Kerlin, MarcinX
2016-10-06 14:20                       ` Thomas Monjalon [this message]
2016-10-06 14:52                   ` Thomas Monjalon
2016-10-07 12:23                     ` Kerlin, MarcinX
2016-10-11  8:52                       ` Thomas Monjalon
2016-09-30 14:24                 ` [PATCH v5 2/2] app/testpmd: improve handling of multiprocess Marcin Kerlin
2016-09-30 15:02                   ` Pattan, Reshma
2016-09-30 15:03                 ` [PATCH v5 0/2] app/testpmd: improve multiprocess support Pattan, Reshma
2016-10-18  7:57                 ` Sergio Gonzalez Monroy
2016-09-27 11:13             ` [PATCH v4 2/2] app/testpmd: improve handling of multiprocess Marcin Kerlin
2016-09-28 10:57               ` Pattan, Reshma
2016-09-28 11:34                 ` Kerlin, MarcinX
2016-09-28 12:08                   ` Pattan, Reshma
2016-09-26 14:53         ` [PATCH v3 " Marcin Kerlin
2016-09-20 14:31     ` [PATCH v2 " Marcin Kerlin
2016-09-02  8:58 ` [PATCH " Marcin Kerlin

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=1556703.BdlfNHUksg@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=dev@dpdk.org \
    --cc=marcinx.kerlin@intel.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=sergio.gonzalez.monroy@intel.com \
    /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.