From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8D57AA00E6 for ; Tue, 6 Aug 2019 17:40:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 592EE1B502; Tue, 6 Aug 2019 17:40:05 +0200 (CEST) Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by dpdk.org (Postfix) with ESMTP id 732F55B34 for ; Tue, 6 Aug 2019 17:40:04 +0200 (CEST) Received: by mail-pg1-f193.google.com with SMTP id n4so64871pgv.2 for ; Tue, 06 Aug 2019 08:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=vwi4P3rn1Ekli4QzGuOIaMYakfnpVarEgu9TePGPrQA=; b=fbssCFBDgPhatV5VV4ohJJHBQSMOpHtWQ37r9VssGL9EbOibSU2wrdT0UtVazV77x/ oR7T6vOrQ9/Z2wZVMfHSsG1uP/JgcpoGGr2G+ElyVpGHRspfOY+NuSsIU9br3xvchmpC yR0isFWDT7NfxQR1S+hYW3GcyW5iZlIL2R00Sa8PDugwdilsOT/XK64jxzmFaLmERuOB DFfivs9anca4Ck9fko4L2eC9MsS1Nv06MEvKEjJ6RXo5pqwUIVrMPVT9r2TD2rqaN0Vs c2uJHicqx5tUBqLT6n1x6tb80uBCispXSjNKxnU8y8C30vFI0FHiF9FxRdwpIV9vfd3/ Axag== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=vwi4P3rn1Ekli4QzGuOIaMYakfnpVarEgu9TePGPrQA=; b=Zl6NMHR+SB7m457rueNSDuoJ0JTiF5tQmpz82UJzLXcnNJi/RIjrLnws+WUEez/WZY Ccc/ctP6R7CCA3P/JFeZax2vA5Tx/nugrSBSjZeeCYf0r3pKVcaHPsLPnB0j0Ie46j3i +AeJvhqs2Og0psWrCbk0TjygwKLQDR1EQyYuwDrVzyUXBrmw/xnTIlEwEX/30O9fWR0b vcsGcAWlm6H3LUcM83kUiObRLZpHBfzVx8EiCstFg+HZyIi2dafGbHRKaxXAun3g2y83 lOeimG3otwkCaZPwXWsqKA609cz9jR2WZs5CtUYJVteS06vEORkiIo21IghFagoucNNz +kHA== X-Gm-Message-State: APjAAAWOYtWEkqUsmpy0u75cLlwzHd7u4kj9WZlyRBqWl7NCePZUNIRD 82JnNoWIdDyuF7cd6tXVoTZYOg== X-Google-Smtp-Source: APXvYqwg4dkE54oWisyjD+2sbdbuG4+BshNsGHHoZZvfmXkjByBMwS6KSltRtBtGdbGMKBRuNYkJfw== X-Received: by 2002:a17:90a:21ac:: with SMTP id q41mr3935837pjc.31.1565106003306; Tue, 06 Aug 2019 08:40:03 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id g18sm135006751pgm.9.2019.08.06.08.40.02 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 06 Aug 2019 08:40:02 -0700 (PDT) Date: Tue, 6 Aug 2019 08:39:55 -0700 From: Stephen Hemminger To: Matan Azrad Cc: "dev@dpdk.org" , Stephen Hemminger Message-ID: <20190806083955.59124799@hermes.lan> In-Reply-To: References: <20190726165054.24078-1-stephen@networkplumber.org> <20190802025826.1174-1-stephen@networkplumber.org> <20190802025826.1174-2-stephen@networkplumber.org> <20190802085301.02ab5b55@hermes.lan> <20190805090054.1511b033@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v5 1/4] examples/multi_process/client_server_mp: check port validity X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 6 Aug 2019 08:19:01 +0000 Matan Azrad wrote: > From: Stephen Hemminger > > On Sun, 4 Aug 2019 08:31:54 +0000 > > Matan Azrad wrote: > > > > > > > > /* convert parameter to a number and verify */ > > > > > > pm = strtoul(portmask, &end, 16); > > > > > > - if (end == NULL || *end != '\0' || pm == 0) > > > > > > + if (end == NULL || *end != '\0' || pm > UINT16_MAX || pm > > == 0) > > > > > > > > > > Why pm > UINT16_MAX ? should be something like > (1 << > > > > RTE_MAX_ETHPORTS) - 1. > > > > > And need to be sure pm type can hold RTE_MAX_ETHPORTS bits, > > > > otherwise port 0 may unlikely be all the time visible in the loop below. > > > > > > > > > > > > > The DPDK assumes a lot of places that unsigned long will hold a port > > mask. > > > > > > So, all are bugs, no? > > > > I don't think 32 bit build is that well tested. But yes a mask needs to hold 64 > > ports. > > What if someone changes RTE_MAX_ETHPORTS to be bigger than 64 in config file? > > Assume the user changes RTE_MAX_ETHPORTS to 128, and there is a valid port in range [64, 127]. > Then, assume the failsafe sub device owns port ID 0. > > Because the mask bits are not enough to handle the above range, you will get port 0 as valid port - bug. > > I think you need one more check to the RTE_MAX_ETHPORTS > 64 case. Not really needed. The DPDK has lots of hard coded assumptions of all ports fitting in 64 bits. Examples include testpmd/parameters.c etc. The original concept of a small set of assigned values for portid is not going to scale. It really should have been more like ifindex; something that is not used by common API's much larger range; and assigned purely sequentially. The API's should all be using names, but the DPDK port naming is also a mess...