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 3083743EF9; Wed, 24 Apr 2024 21:05:06 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A980040691; Wed, 24 Apr 2024 21:05:05 +0200 (CEST) Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by mails.dpdk.org (Postfix) with ESMTP id 8B65C40689 for <dev@dpdk.org>; Wed, 24 Apr 2024 21:05:03 +0200 (CEST) Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1e3ca4fe4cfso1325885ad.2 for <dev@dpdk.org>; Wed, 24 Apr 2024 12:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1713985502; x=1714590302; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=BlZyBVRkNZuT2TmWxwfxJ5qV8KLgLLRincxfITKFaho=; b=miHUEnY7AfSmQNv5rT+oDLZpZ0mkSverqD+FhvnAdoAUiPCqyJo/zzs6i6gnzavTPq 4u2oSAuX1+YM3TUsFdC6/WZ3CiZfpqVrmolm/bih4VyuEdVnV5xsaqaaaNXX/nN2VHx0 a7hdH89Ggunxg+2hpvqpJpPoc1fPUO8yHDLJo31TvLYYAV2Z7tn3JsAKsFKatgNKnAI7 Sn+HvgwlT2VWety/DhIVE0P+f4aIDN4E9e3DqmoMZ3zCwPLrudWM+ttKjozhA6QSlPfO i7ONloAP45oVx8oboG+p+SgdCEFGAm0Z+r5FvHSQRm4LB436YCVCTMLXcJAQo1BQ/+6x OXog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713985502; x=1714590302; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BlZyBVRkNZuT2TmWxwfxJ5qV8KLgLLRincxfITKFaho=; b=OeaucMitOeGurIcqZ0V/baIrcmdnOIkrku0T2Lxtm4y9/hBCuIMVrociqi9Pux4KIw LV5Mu28tKpmY9MFoROove5bs0wgKClU25uTX7v9S2b2AWRQp6rfQJPCWsuZPmvxMklTK JaHWUuTGz6PwbDPYqJtKgIVTTcBiTet5T1Gg9nooecpWvNMSH36hBMZNN9eTLSTa88rJ or8hfeCMeqLt2kHx61txA5W1UK3EvZSz8bOc63DhxyrrBlSouLPQJTUBKLB8+898sdOu lAELspg8MDIdJ34T1EKG4yREmRCkgeAPCQiESLii8MrFH91wOKfBJ6l+dM4d3ZqjpcL/ sz/Q== X-Gm-Message-State: AOJu0YwhElDfVU93V6nIIPRs8HBOb6243RHUFEBbDWXl42Mugm53+HvZ 2/ektnQFr5LUHVUglXvB8FpW4rC4wm1QmAKJpssYKF9Ly3+nlhx/BH5deQHZaKk= X-Google-Smtp-Source: AGHT+IGv2Ua+gqp7TQokK73RBlgs9PkJ+YSSN7zEBKkgXcOZCEHFC5vyA+9jd6BdDjDRU54bPG97HA== X-Received: by 2002:a17:903:1110:b0:1e4:3386:349f with SMTP id n16-20020a170903111000b001e43386349fmr3773359plh.51.1713985502358; Wed, 24 Apr 2024 12:05:02 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id q9-20020a170902a3c900b001e3dff1e4d1sm7104679plb.268.2024.04.24.12.05.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Apr 2024 12:05:02 -0700 (PDT) Date: Wed, 24 Apr 2024 12:04:59 -0700 From: Stephen Hemminger <stephen@networkplumber.org> To: Ferruh Yigit <ferruh.yigit@amd.com> Cc: dev@dpdk.org Subject: Re: [PATCH v4] tap: do not duplicate fd's Message-ID: <20240424120459.61030d5c@hermes.local> In-Reply-To: <fbdc8c75-1c72-44a7-a5aa-8a817b6e8154@amd.com> References: <0240308185401.150651-1-stephen@networkplumber.org> <20240311194543.39690-1-stephen@networkplumber.org> <fbdc8c75-1c72-44a7-a5aa-8a817b6e8154@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Wed, 24 Apr 2024 17:57:46 +0100 Ferruh Yigit <ferruh.yigit@amd.com> wrote: > OK to merge file descriptors instead of duplicating them. > > But we have this 4 queue limitation only for multi process case, right? > If user is planning to use only with primary, this will reduce the > supported queue number. > > Does it make sense to enforce this limitation for secondary only and > keep TAP_MAX_QUEUES same? > So for multi process usecase supported queue number will be 8, for > primary only use case it will remain 16. > > <...> Yes, the lower limit only applies to the secondary process. But any application using secondary processes will have the problem; i.e it is not that primary gets 16 and the secondary only sees 8. Lets keep MAX_QUEUES at 16 for now, and let users see the warning. For 24.11 up the max passed fd's to what Linux allows.