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 06943A00E6 for ; Wed, 7 Aug 2019 01:09:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F02881B942; Wed, 7 Aug 2019 01:09:22 +0200 (CEST) Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by dpdk.org (Postfix) with ESMTP id 803671B93E for ; Wed, 7 Aug 2019 01:09:21 +0200 (CEST) Received: by mail-pf1-f195.google.com with SMTP id p184so42318885pfp.7 for ; Tue, 06 Aug 2019 16:09:21 -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=qLGvp3Jsem/pCpKYbRpcPMQFPl98wPEQxDKQrPr16pc=; b=UZVCcS+65vBWke/mcpAu0QtF++L9w0+WztY4vJv1JUImFPRl0RqjYyVhAb0+8VI2Dm DJlB65W4Y9L+ZlRlBPcMEFLA9u0Gq8Yl/dPTyrgRnofNSGR+DEUqfxkKKgmZXAw1MCdV Sy0eJE1H0hTtbC+1/4XbtxpnTU610Mh3tUvYtE7AuZvzAwlf3i6ndE1LtQyhrTsvDD8h pr/n3yzwbJVmE1r+JfxfM+gxmOkumYObEBkZk10P0Zk9Nb1/R3qZo7YhoNl+9k7WtKNk SrFbI4uNe5gxyrTOUlBvhaRwBqKCOzoJ4256OlH6wC0Xgc37PdbXlYoc50mt0+naC2Ef XfXw== 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=qLGvp3Jsem/pCpKYbRpcPMQFPl98wPEQxDKQrPr16pc=; b=hLhKLshcx/Wz2q1AkXTjGYraRCG/NsbkuUGYHzpGOhAIdLjfJ273d/pl51vsp+mCgi wET4o7qo/oseyCURHOFz8X+Q6dZ58qQXUFCmHinUKaxBgZxKXsaw0bgMIgo4/+LkUVCc MvTV3/CYKLz9DCqe+iPuhr6pta5bD4NFM34Q2G8IMv/dsTQgl2vmLPRPJDznCvuVHOGr 6STLQD0hKr2sxWD5Ex6wZHLgB7mDD4iOYS3c7zcwkJqhQ1ci36g8YOvOWLN5vedyAbPx XsCsBbgeQzZ9jpopZeSNQ7N0HBJAnH512psArkL+dnVYhIwwvo3P6/DiJgApxW3xeunx K7dQ== X-Gm-Message-State: APjAAAXUPfqQbONhQhvT5cO8jcUfvJll/AqbAOWj/kZ5w7gnlMXByWlG rHAXQDZRLpAA3mbFi0SuExHRtQ== X-Google-Smtp-Source: APXvYqyIVSSxIF/cK03qHUD7ws0ly+z0Mo069jrC6UCN/9pnLkpeQXD4ZJFOseXIWWY9ArXsOYVAUg== X-Received: by 2002:a62:1bca:: with SMTP id b193mr6024574pfb.57.1565132960433; Tue, 06 Aug 2019 16:09:20 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id f197sm87425098pfa.161.2019.08.06.16.09.20 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 06 Aug 2019 16:09:20 -0700 (PDT) Date: Tue, 6 Aug 2019 16:09:13 -0700 From: Stephen Hemminger To: Matan Azrad Cc: "dev@dpdk.org" , Stephen Hemminger Message-ID: <20190806160913.62e0d15d@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> <20190806083955.59124799@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 20:03:22 +0000 Matan Azrad wrote: > > > > The DPDK has lots of hard coded assumptions of all ports fitting in 64 bits. > > Examples include testpmd/parameters.c etc. > > Yes, I understand, but the user should know not to change the default value of > RTE_MAX_ETHPORTS, at least it should be documented. > > > 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... > > Port ID is OK, user can run port info, then to find the wanted port ID and configure it by port id list\bitmap. > The examples are toy programs. If user changes RTE_MAX_ETHPORTS it will break lots of other places. Why put more checks in the examples. Sorry, it really would not help to pretend that fixing the example is going to help this. The original code was broken with behavior introduced with port ownership and these patches try to help fix that. Still think Port ID is a lousy API for real applications. It is fine for the DPDK literati but terrible user experience for the average user. It requires too hands on an experience. For example, the port id values change in non-obvious ways when using port ownership like failsafe does.