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 93DFCA00E6 for ; Wed, 7 Aug 2019 17:15:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2DC402C58; Wed, 7 Aug 2019 17:15:54 +0200 (CEST) Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) by dpdk.org (Postfix) with ESMTP id 1C3A02C02 for ; Wed, 7 Aug 2019 17:15:52 +0200 (CEST) Received: by mail-pl1-f193.google.com with SMTP id 4so34291465pld.10 for ; Wed, 07 Aug 2019 08:15:52 -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=B/iE4O9TMZNHCJueP1SSAqyNIYplfs0WBiZjYBwSpwo=; b=hHkidelqad1m2dZzzRPoJR/danNJ/vf7oZRw6DWOyEl6Mmg61+iZSFv1042tUoA8UZ 39SpAThkFqccvKgAdDp2iXNIccDWrGdi4fXbL3TF65ifam0rkHwpH7hIhUKF7fF50rfT D1xDY+XmaW+mqQGAEsQdl4osBFoYHvDWAhp/yikKZoOoTFNRsaVnZk86blzuNYY7PQQF RN0hh/Bokst/zF/YA8M17KtU98rY5RqVF7pTr+dh1sTqGVqj8xmrPCBwZSjw8PyAU/UI yocT+8VCE5qToMqWLkx4VutgBn0eIwBtnchx1ziKc8CDQyVPhxGm/sq6QtRBm/zlgT7t Ontg== 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=B/iE4O9TMZNHCJueP1SSAqyNIYplfs0WBiZjYBwSpwo=; b=JsnBESSDnS0MJ7b+8VNB1KGtM3dBiou2Ux85N6HkqBy+QwJAsgdrI+p4D5GMWSDoV5 zz1StufJwN9atbqX2/WkhfHR81J+7pOQc55inL7Pb11oVFLWaL/1jpcu+3Z+R/YwC6uy Ub/cxnAbJAeDPv88evxuuaoQTUsnDy+WZ1p4wnQVSBpAE61xCSHKtIJP0RBODNO1RwBj 6HmGk3xR8XW5xuyTqWca6b+WkteU46WVgd/HR/oGZkpr+drqME7xIzoQXpARJJGl3Mjn /4LlFku3wqI0E2wEp6qMW5iB08vCo1dniYXn/s7C08cGIeanJI0jPsE8kY+fzFyFxMjI rp/Q== X-Gm-Message-State: APjAAAUnZaXPTZLMEfEE88wlFEWX6IE2Io8pJIKvIB4RAfvO98wJz/m6 RS+PL48RvPZ9IxezB0Hptbnjqg== X-Google-Smtp-Source: APXvYqyHoVR+xKxfyjynGvPAuLKwVYT9CgoQYmLuTLATsnOkXoge5hpfL6CIh6f4RMWqqA6pktYkMw== X-Received: by 2002:a17:90a:a489:: with SMTP id z9mr440181pjp.24.1565190951135; Wed, 07 Aug 2019 08:15:51 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id b26sm101170209pfo.129.2019.08.07.08.15.50 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 07 Aug 2019 08:15:51 -0700 (PDT) Date: Wed, 7 Aug 2019 08:15:43 -0700 From: Stephen Hemminger To: Matan Azrad Cc: "dev@dpdk.org" , Stephen Hemminger Message-ID: <20190807081543.533c1122@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> <20190806160913.62e0d15d@hermes.lan> <20190806225308.736f15ef@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 Wed, 7 Aug 2019 07:02:02 +0000 Matan Azrad wrote: > From: Stephen Hemminger > > On Wed, 7 Aug 2019 05:38:42 +0000 > > Matan Azrad wrote: > > > > > From: Stephen Hemminger > > > > Sent: Wednesday, August 7, 2019 2:09 AM > > > > To: Matan Azrad > > > > Cc: dev@dpdk.org; Stephen Hemminger > > > > Subject: Re: [dpdk-dev] [PATCH v5 1/4] > > > > examples/multi_process/client_server_mp: check port validity > > > > > > > > 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. > > > > > > > > > Agree that it is not needed to fix all the places now. > > > It is better just to update the example documentation that > > RTE_MAX_ETHPORTS must not be changed when running this application. > > > > > > I will ack your series(v7) , Consider to update the doc if you want to be > > completely perfect here. > > > > Perhaps the right place to tell the users is somewhere in the documentation? > > > > One place would be here: > > > > diff --git a/doc/guides/faq/faq.rst b/doc/guides/faq/faq.rst index > > f19c1389b6af..a847d9ceda22 100644 > > --- a/doc/guides/faq/faq.rst > > +++ b/doc/guides/faq/faq.rst > > @@ -195,3 +195,8 @@ Why can't my application receive packets on my > > system with UEFI Secure Boot enab > > > > If UEFI secure boot is enabled, the Linux kernel may disallow the use of UIO > > on the system. > > Therefore, devices for use by DPDK should be bound to the ``vfio-pci`` > > kernel module rather than ``igb_uio`` or ``uio_pci_generic``. > > + > > +What is the maximum number of ethernet devices? > > +----------------------------------------------- > > + > > +The limit on the number of Ethernet devices is controlled by the > > RTE_MAX_ETHPORTS configuration setting. Since many of the applications > > use a 64 bit value for port mask; the current upper limit is 64 ports. > > > I think there are systems with a lot of virtual ports which may use more than 64. > > So update all the docs when the mask is defined, would be option too. It would be good if (ie someone should do it but I don't have time); to have a new type "port_set" which is a variable length bit mask It could be backwards compatible with existing usage. Something like existing cpuset command format. Examples of the Mask Format: 00000001 # just bit 0 set 40000000,00000000,00000000 # just bit 94 set 00000001,00000000,00000000 # just bit 64 set 000000ff,00000000 # bits 32-39 set 00000000,000e3862 # 1,5,6,11-13,17-19 set