From patchwork Fri Mar 8 20:36:39 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 138136 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6006A43C27; Fri, 8 Mar 2024 21:37:44 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E560A40291; Fri, 8 Mar 2024 21:37:43 +0100 (CET) Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by mails.dpdk.org (Postfix) with ESMTP id 6C54440274 for ; Fri, 8 Mar 2024 21:37:42 +0100 (CET) Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-6e64a9df6c3so1965499b3a.3 for ; Fri, 08 Mar 2024 12:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1709930261; x=1710535061; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=F+YPsui6H8BiiJAGDCGMuN+kDq0tYgIDg+MSyvZ7cqI=; b=Dz5JGv9pH2uLgmHLvfxq5/X7Fp1PpdWf4LGkVtxtgIlFXt/MnxzOiUWZsGhmdcYcRb e9voIpS3THtZBq75zchcInR/mENppqNQLrk5zF3qX1GY7KD1NXV6YbAm2C40Iq6/WAM5 NgdngIAF5RWgNKVDekJi/Gq6iAKEwhLuIZaKLv2k2G87pd0SyMgGdiS+hB0P6M676zzD oUs+LsMeamPC56VVt2rgq1d8ZeLjytPrwVYsv0ZUK86jNhM74pWYo+R80x5n9GfuNPua IyM3Kcn3vA+sj5w3tp0s6+EJuz+r19YMeG1qIVAF+3LK7tm23piD8f735+uHz4EkpDjA 5LXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709930261; x=1710535061; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=F+YPsui6H8BiiJAGDCGMuN+kDq0tYgIDg+MSyvZ7cqI=; b=A9UvjJyXFwSY0eUJVXOLD0Utmg+OgoB1YZSJE1mBOH8R7rZXDLXTFSmjuN6g0USn8A W1gnFfs3FcVNvVsHZ4JbGsExDKz258ox4vdXWvkD75R11I+aP4Hcuv/w9jzjKzJ71gxS uGqnRrevg2DaJ6pjbRCCQtpd/ZDSEKp+93xA/fqzsWprtqbKxL7GnPF5RJFT2CCXCl3E Rn0Qygy1AzyL4v4I75WcJViDS41Y/C3Ij2vO5zr964jAqBNJ9ykk56TFSXDvCPdL67iv Kqm0kn5kNUabUdM2wVehNutfg8aYpFyTQC0mN/U7HytjCg8bOmRvs4aQrOXbx620m1qi j8YA== X-Gm-Message-State: AOJu0YyaWQSEWf8bS8fa/A7GY2HUxkSbeXeoCYHk+Gg4D4ENW7x4sj+D UTIeGvFAyuQBlL2Lq9ObGzysjdwBeLSnaD3UL2Pke4WMQ1l/qOAVGHUWDHADccyxuuCQWVITv3j ZOks= X-Google-Smtp-Source: AGHT+IGMbEfSx0/eRhZmxUNptNHPLbdtl/uVOcz7Qx+AjTyuCt2vDcob0vtbJeHOQ3mCvoY4FL1i1Q== X-Received: by 2002:a05:6a20:a621:b0:19e:9a97:cb12 with SMTP id bb33-20020a056a20a62100b0019e9a97cb12mr109607pzb.54.1709930261517; Fri, 08 Mar 2024 12:37:41 -0800 (PST) Received: from hermes.lan (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id f15-20020a056a00228f00b006e3a69eb6c4sm100181pfe.219.2024.03.08.12.37.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Mar 2024 12:37:41 -0800 (PST) From: Stephen Hemminger To: dev@dpdk.org Cc: Stephen Hemminger , Anatoly Burakov , Jianfeng Tan Subject: [RFC v2] eal: increase passed max multi-process file descriptors Date: Fri, 8 Mar 2024 12:36:39 -0800 Message-ID: <20240308203737.208999-1-stephen@networkplumber.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240308185401.150651-1-stephen@networkplumber.org> References: <20240308185401.150651-1-stephen@networkplumber.org> MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Both XDP and TAP device are limited in the number of queues because of limitations on the number of file descriptors that are allowed. The original choice of 8 was too low; the allowed maximum is 253 according to unix(7) man page. This may look like a serious ABI breakage but it is not. It is simpler for everyone if the limit is increased rather than building a parallel set of calls. The case that matters is older application registering MP support with the newer version of EAL. In this case, since the old application will always send the more compact structure (less possible fd's) it is OK. Request (for up to 8 fds) sent to EAL. - EAL only references up to num_fds. - The area past the old fd array is not accessed. Reply callback: - EAL will pass pointer to the new (larger structure), the old callback will only look at the first part of the fd array (num_fds <= 8). - Since primary and secondary must both be from same DPDK version there is normal way that a reply with more fd's could be possible. The only case is the same as above, where application requested something that would break in old version and now succeeds. The one possible incompatibility is that if application passed a larger number of fd's (32?) and expected an error. Now it will succeed and get passed through. Fixes: bacaa2754017 ("eal: add channel for multi-process communication") Signed-off-by: Stephen Hemminger --- v2 - show the simpler way to address with some minor ABI issue doc/guides/rel_notes/release_24_03.rst | 4 ++++ lib/eal/include/rte_eal.h | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/doc/guides/rel_notes/release_24_03.rst b/doc/guides/rel_notes/release_24_03.rst index 932688ca4d82..1d33cfa15dfb 100644 --- a/doc/guides/rel_notes/release_24_03.rst +++ b/doc/guides/rel_notes/release_24_03.rst @@ -225,6 +225,10 @@ API Changes * ethdev: Renamed structure ``rte_flow_action_modify_data`` to be ``rte_flow_field_data`` for more generic usage. +* eal: The maximum number of file descriptors allowed to be passed in + multi-process requests is increased from 8 to the maximum possible on + Linux unix domain sockets 253. This allows for more queues on XDP and + TAP device. ABI Changes ----------- diff --git a/lib/eal/include/rte_eal.h b/lib/eal/include/rte_eal.h index c2256f832e51..cd84fcdd1bdb 100644 --- a/lib/eal/include/rte_eal.h +++ b/lib/eal/include/rte_eal.h @@ -155,7 +155,7 @@ int rte_eal_primary_proc_alive(const char *config_file_path); */ bool rte_mp_disable(void); -#define RTE_MP_MAX_FD_NUM 8 /* The max amount of fds */ +#define RTE_MP_MAX_FD_NUM 253 /* The max amount of fds */ #define RTE_MP_MAX_NAME_LEN 64 /* The max length of action name */ #define RTE_MP_MAX_PARAM_LEN 256 /* The max length of param */ struct rte_mp_msg {