From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C640C43CA6; Thu, 14 Mar 2024 16:23:32 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B0DEE40E28; Thu, 14 Mar 2024 16:23:32 +0100 (CET) Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by mails.dpdk.org (Postfix) with ESMTP id 225A440297 for ; Thu, 14 Mar 2024 16:23:32 +0100 (CET) Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1dedb92e540so5088055ad.0 for ; Thu, 14 Mar 2024 08:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1710429811; x=1711034611; 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=IvAREzxxIa9ajlY7nVKB+6+a4JHPDW97d4OuPUh+jfE=; b=Z+xCQIgOBBKkJZCRrvoY22trf5184p58bZRkjdCy1RRAk3HThKEUDFbAXqzSvD+gcK X9cIJvvNUXKriQfbKdG9QyGCRSBXY5aRUOF7pbp95xPXXEJv9ulTs64XBoWQhCMsU32R nEGpE7IHh8aeTiAeGbvZsXOvsKsI0AvWnXrdNREYWfC10qvU56sgL596rGkh1HTFv+1z H/r058fLXh8bSITQnmG6TeU1/iwIIwp17ikDGcDI3sHldrmH84+GOsfCF78kEeTSH9dW wnPihUGaVJNmNoVXXBjIH6EGNNmSIEQJ+nbuKxr9WbkWxiReytY5YEw04wyGBgtUPW2Z Eq9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710429811; x=1711034611; 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=IvAREzxxIa9ajlY7nVKB+6+a4JHPDW97d4OuPUh+jfE=; b=sE3dX9104yESFw38VN9P6MDxHDD0i/c9s2qiv8cD2NuM+eAIST3lt3PClLGtWDjq7y MERV7iXDBZPb5cKNr1NuqRLQD9ZrETSEGIT5xwZTroqur7ODOjjPxrLfrA3x1OvNltk0 knHLEJm61ty38d+WymwS7llilgINMZgpxz+58MnCzpO0QnwKUD3P7Wtrtl+y/biKK4H+ p8JT3ch8zzm0cGrrH0lGTbn/IhDZqFlzIrVkrWV5A9DTW8FbU7dzlYfuenwtj9vtSx9l aSyZAaiKnzw2ZKTZlkCdQW9mIq84gafa+fRms6rPs34G9VM9DnvCYJQUG6F3dT0YLf4x xpGw== X-Gm-Message-State: AOJu0YxmYfGRj+3cMNnqyAH/KRgKinQGBUQlVQny2828ckJ0MLUyKvqB WsapPPPBcSFf7XYDlNQhwnsNOntzW6ogYX+KpkF9ROtKXSuHHiNBGzB9PhO1Mrb9luKFJ5kgs2G j X-Google-Smtp-Source: AGHT+IGRAiV6T+f0XNcuKgipfcqQYtWuqmeDeMhzlOuZZuN0aXljj7waBAACUGR9cEcMM0I+E5vyyw== X-Received: by 2002:a17:902:f688:b0:1dd:9250:2d58 with SMTP id l8-20020a170902f68800b001dd92502d58mr3080358plg.18.1710429811198; Thu, 14 Mar 2024 08:23:31 -0700 (PDT) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id j1-20020a170902c3c100b001ddb57a4dffsm1826726plj.132.2024.03.14.08.23.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Mar 2024 08:23:30 -0700 (PDT) Date: Thu, 14 Mar 2024 08:23:28 -0700 From: Stephen Hemminger To: dev@dpdk.org Cc: Anatoly Burakov , Jianfeng Tan Subject: Re: [RFC v2] eal: increase passed max multi-process file descriptors Message-ID: <20240314082328.3d97808c@hermes.local> In-Reply-To: <20240308203737.208999-1-stephen@networkplumber.org> References: <20240308185401.150651-1-stephen@networkplumber.org> <20240308203737.208999-1-stephen@networkplumber.org> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, 8 Mar 2024 12:36:39 -0800 Stephen Hemminger wrote: > 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 { Rather than mess with versioning everything, probably better to just hold off to 24.11 release and do the change there. It will limit xdp and tap PMD's to 8 queues but no user has been demanding more yet.