From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com [209.85.128.182]) by dpdk.org (Postfix) with ESMTP id 0B9A21B3DF for ; Wed, 9 May 2018 16:03:48 +0200 (CEST) Received: by mail-wr0-f182.google.com with SMTP id g21-v6so35732503wrb.8 for ; Wed, 09 May 2018 07:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=ZjvysQCByD7Ax0N/tBrxIdrJ3TO+lHNW95bAZVDTZhk=; b=YHqnoqiELNgz5cVy7bkwhL1BHpjQNC05+1bKq+EWytaYX5rLCYwSpIChcEWBi8g0+Z XhgJ/cS9A6qpg+/R7HvZTWpbiyJ23twu0vxWZKY8zauJ6duPqYQPPAJjcmm6/O9Sm9ly TdwkAUtSOEQcrBwa379BTHArioOxuAA04//8zwK1ASx1AL1wNkDWqBE1wrKcL+09dojS +Fhw03Yp70xUNZcrsTazwWU9aYBs2RTG3PJh7C4bxrvPCB2Ivh70FnNq8+RQbz1asHXA w6pXp5Bkt109WpAU9GsYKd671P4D3fZNgodzAC9orKU49KjWK7EyqJwA8pKNIahVdHnm Meug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=ZjvysQCByD7Ax0N/tBrxIdrJ3TO+lHNW95bAZVDTZhk=; b=pFFwgQv9eHqQ2j+n8sydY0Hr3Y/OwROq5b4nS+RCMNfEGSXGIWm0u/kdJ9bZAJ5Vjw rFgv1ZRPtoaQC95spd2oiRF6FWcj3t3GTP/0cTqbhMAxRAh4ACYUioG+nb4ior3IA+2r KqK94EHc5+XlIxICGUHHp9PH9DRWLo+nY6XE+4i0PSlVk6SjkII4YnQCC1I+LqzIyZGH 9A3G7wm5uQyBqAnp+w+STnQ403HQThszSIJTiR1K8kPsnGXgMQD83jSMUrXADfxSsUr2 TPJu8dlpqUphMVRIPHyraMn19bfIO7ehIxURnMdQJVJ0VH2xWiSzJS+gwwKX4uCMzaZx j2+Q== X-Gm-Message-State: ALQs6tCe5agNBO4AeRoC4q0Bx9bh8IetVbcvscN1vQ0Y0nOPa9xBesqu Y54zFNW4fqNOmkfiXr0d6YaUNZ7W X-Google-Smtp-Source: AB8JxZpG2MErGUpw5jlPDu7dqBmFv8O/CkSu/5VrN8VYB/zxHLUz41pIRQVu55q/GDujPSsPIGcuzQ== X-Received: by 2002:adf:81c2:: with SMTP id 60-v6mr36072568wra.13.1525874628702; Wed, 09 May 2018 07:03:48 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id k30-v6sm51561305wrf.17.2018.05.09.07.03.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 09 May 2018 07:03:47 -0700 (PDT) Date: Wed, 9 May 2018 16:03:33 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Thomas Monjalon Cc: Matan Azrad , "dev@dpdk.org" , "stable@dpdk.org" Message-ID: <20180509140333.kb6pmbno2ixzuj7p@bidouze.vm.6wind.com> References: <20180509094337.26112-1-thomas@monjalon.net> <20180509133013.yxy66njakty2g7y2@bidouze.vm.6wind.com> <10613870.Sdbp1i1ck2@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <10613870.Sdbp1i1ck2@xps> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH 10/11] net/failsafe: fix sub-device ownership race X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 14:03:49 -0000 On Wed, May 09, 2018 at 03:43:31PM +0200, Thomas Monjalon wrote: > 09/05/2018 15:30, Gaëtan Rivet: > > On Wed, May 09, 2018 at 01:01:58PM +0000, Matan Azrad wrote: > > > Regarding uint32 > > > The maximum port id number can be 0xffff. > > > In this case the loop will be infinite if we use uint16 to iterate over all the ports. > > > > If RTE_MAX_ETHPORTS is set to 0xffff, an array rte_eth_devices[0xffff] > > would be defined statically, and I think other issues would arise > > before our being stuck in an infinite loop? > > > > In any case, if this had to be fixed, then there should be a > > BUILD_BUG_ON RTE_MAX_ETHPORTS being 0xffff, in the relevant part of > > librte_ethdev, instead of relying on librte_ethdev users skirting > > shortfalls of the library. Anyone iterating on port IDs should expect the > > port_id type to be sufficient to hold this information. > > Interesting thought. > I vote for keeping Matan's option as it is correct, > and will accept a patch in 18.08 for your option (BUILD_BUG_ON). > Maybe we should send a deprecation notice before limiting the max > number of ports to 0xfffe? Or is it ridiculous for such unlikely constraint? > > No actually the issue is when RTE_MAX_ETHPORTS is equal (or superior) to 0x10000. If this is an issue that you think is worth having a workaround here, you should also consider that rte_eth_find_next_owned_by (and rte_eth_find_next, even if this one should be phased out), would also result in an overflow and an infinite loop. -- Gaëtan Rivet 6WIND