DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Ferriter, Cian" <cian.ferriter@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] lib/librte_ether: change socket_id passed to rte_memzone_reserve
Date: Wed, 14 Jan 2015 10:09:49 +0000	[thread overview]
Message-ID: <20150114100946.GA10476@bricha3-MOBL3> (raw)
In-Reply-To: <D9B9B7EDAA4D17468E64B453458633E4044EA5E5@IRSMSX108.ger.corp.intel.com>

On Tue, Jan 13, 2015 at 06:05:25PM +0000, Ferriter, Cian wrote:
> Comments on alternative solutions:
> 1) how would this solution work when there is no NIC present, and "rte_eth_from_rings" is called? Here, could you have an else where the socket id of the master core is passed to the "memzone_reserve"?
> 2) how would you advise making this change? I have looked at where "rte_eth_dev_allocate" is being called and in all but one case, there is a "numa_id" that could be passed in. This isn't the case for " rte_eth_dev_init" however, is there an easy solution for this? Would there now need to be an "rte_eth_dev_data" struct for each socket that there is a NIC attached to, reserving memory from that socket?
> 
> Cian

While I think the issues you highlight can probably be overcome, I'm not so
sure any more how much it matters what numa node this is allocated on. The 
ethdev data for any port in use by a port should be in the cache. In that case,
if it doesn't matter, your original suggestion would work fine.

	/Bruce

> 
> -----Original Message-----
> From: Richardson, Bruce 
> Sent: Tuesday, January 13, 2015 1:56 PM
> To: Ferriter, Cian
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] lib/librte_ether: change socket_id passed to rte_memzone_reserve
> 
> On Tue, Jan 13, 2015 at 09:23:16AM +0000, Ferriter, Cian wrote:
> > Passing a socket id of "rte_socket_id()" can cause problems in non DPDK applications as there is a dependency on the current logical core we are running on.
> > Passing " rte_lcore_to_socket_id(rte_get_master_lcore())" as the socket id to rte_memzone_reserve resolves these issues as the master lcore doesn't change.
> > 
> 
> The only trouble is that when affinitizing the memory for the NICs to the socket of the master lcore, it gives us no way to correctly configure an app to use NICs connected to two different sockets on the one system. All memory for all NICs will end up on the same socket. Two possible alternative solutions:
> 1) affinitize memory to the socket the NIC is connected to
> 2) add a socket parameter to the API calls to allow the user complete control over their memory allocations
> 
> Obviously the second one breaks backward compatibility (assume we modify existing API call), but is more powerful.
> 
> Thoughts?
> 
> /Bruce
> 
> > -----Original Message-----
> > From: Ferriter, Cian
> > Sent: Tuesday, January 13, 2015 9:22 AM
> > To: dev@dpdk.org
> > Cc: Ferriter, Cian
> > Subject: [PATCH] lib/librte_ether: change socket_id passed to 
> > rte_memzone_reserve
> > 
> > Change the socket id that is passed to rte_memzone_reserve from the socket id of current logical core to the socket id of the master_lcore.
> > ---
> >  lib/librte_ether/rte_ethdev.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)  mode change 100644 
> > => 100755 lib/librte_ether/rte_ethdev.c
> > 
> > diff --git a/lib/librte_ether/rte_ethdev.c 
> > b/lib/librte_ether/rte_ethdev.c old mode 100644 new mode 100755 index 
> > 95f2ceb..835540d
> > --- a/lib/librte_ether/rte_ethdev.c
> > +++ b/lib/librte_ether/rte_ethdev.c
> > @@ -184,7 +184,7 @@ rte_eth_dev_data_alloc(void)
> >  	if (rte_eal_process_type() == RTE_PROC_PRIMARY){
> >  		mz = rte_memzone_reserve(MZ_RTE_ETH_DEV_DATA,
> >  				RTE_MAX_ETHPORTS * sizeof(*rte_eth_dev_data),
> > -				rte_socket_id(), flags);
> > +				rte_lcore_to_socket_id(rte_get_master_lcore()), flags);
> >  	} else
> >  		mz = rte_memzone_lookup(MZ_RTE_ETH_DEV_DATA);
> >  	if (mz == NULL)
> > --
> > 1.7.4.1
> > 

  reply	other threads:[~2015-01-14 10:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-13  9:22 Cian Ferriter
2015-01-13  9:23 ` Ferriter, Cian
2015-01-13 13:55   ` Bruce Richardson
2015-01-13 18:05     ` Ferriter, Cian
2015-01-14 10:09       ` Bruce Richardson [this message]
2015-01-19 18:38         ` Ferriter, Cian
2015-01-22  9:56           ` Ferriter, Cian
2015-01-22 11:26             ` Bruce Richardson
2015-01-13 23:24 ` Stephen Hemminger
2015-01-14 10:13   ` Bruce Richardson
2015-01-22 15:05 Cian Ferriter
2015-01-27  9:29 ` Thomas Monjalon

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=20150114100946.GA10476@bricha3-MOBL3 \
    --to=bruce.richardson@intel.com \
    --cc=cian.ferriter@intel.com \
    --cc=dev@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).