From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 6762CA0508;
	Wed, 13 Apr 2022 09:54:28 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 13BC140E03;
	Wed, 13 Apr 2022 09:54:28 +0200 (CEST)
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by mails.dpdk.org (Postfix) with ESMTP id 2193E40694
 for <dev@dpdk.org>; Wed, 13 Apr 2022 09:54:26 +0200 (CEST)
Received: by linux.microsoft.com (Postfix, from userid 1086)
 id 1CE0920C34B6; Wed, 13 Apr 2022 00:54:25 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 1CE0920C34B6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
 s=default; t=1649836465;
 bh=lePCEDOJP7LPr9/7K1VFcU/ieI2p15A2cLL1Rub9k2c=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=p1/BrcFDCEYelZbNCPftYWFoRQ1YZND3XSK9IYKCfSQYcunnnWJVGNbwt7SFbgqly
 eEDDA7E6tTmB55tm8qRLdRKBn7OzfkOUb9x5KlueNeSiP70h/ShCuZI3flWNK0PE8X
 jnZhF3ZyNgvXPmoB3umCs4xdrmFAM8NG9YKxhWa8=
Date: Wed, 13 Apr 2022 00:54:25 -0700
From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: dev@dpdk.org
Cc: anatoly.burakov@intel.com
Subject: Re: rte_memzone_reserve and invalid socket id
Message-ID: <20220413075425.GA8292@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
References: <20220329060436.GA22196@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220329060436.GA22196@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Mon, Mar 28, 2022 at 11:04:36PM -0700, Tyler Retzlaff wrote:
> hi,
> 
> there is a repeatable test failure in test_memzone when running
> dpdk-test.exe --no-huge for memzone_autotest
> 
> it's clear why the test fails but what isn't clear if what
> rte_memzone_reserve is doing when provided an invalid socket id is
> sensible or not.
> 
> as a matter of luck the system i'm using to test is a single socket
> system and as a result has only socket_id 0. the test however tries to
> use rte_memzone_reserve with a socket_id of 1 which is not a valid
> socket_id on the system.
> 
> 	memzone3 = rte_memzone_reserve(TEST_MEMZONE_NAME("testzone3"), 1000,
> 				1, 0);
>                                 ^ socket_id (to repeat just make it invalid)
> 
> the parameter documentation provided for reference.
> 
>  * @param socket_id
>  *   The socket identifier in the case of
>  *   NUMA. The value can be SOCKET_ID_ANY if there is no NUMA
>  *   constraint for the reserved zone.
> 
> of interest is should rte_memzone_reserve fail when provided a
> completely invalid socket_id?
> 
> when running with --no-huge it does not because when --no-huge the
> socket_id no matter the value is silently re-mapped to SOCKET_ID_ANY
> though without --no-huge if a completely garbage socket_id were provided
> it seems the allocation would fail.
> 
> so you get different behavior for an invalid socket_id depending on
> --no-huge vs with.
> 
> 	if (!rte_eal_has_hugepages() && socket_id < RTE_MAX_NUMA_NODES)
> 		socket_id = SOCKET_ID_ANY;
> 
> the test later fails at this check. where it compares the memzone3
> socket_id to what was used in the call to rte_memzone_reserve.
> 
> 	if (memzone3 != NULL && memzone3->socket_id != 1)
> 		return -1;                ^ SOCKET_ID_ANY if --no-huge
> 
> if the allocation had failed, the test would pass instead of failing at
> this point.
> 
> so what's wrong here? the test should be changed to expect different
> behavior with --no-huge vs huge or should rte_memzone_reserve be
> explicitly requiring SOCKET_ID_ANY instead of re-mapping invalid socket
> id?
> 
> if it isn't the test that is wrong then a compatibility discussion is of
> interest but i'm avoiding that until someone confirms the intended
> design/behavior.
> 
> thanks

ping? does the community have an opinion here?