From mboxrd@z Thu Jan 1 00:00:00 1970 From: Iain Barker Subject: Re: Question about DPDK hugepage fd change Date: Tue, 5 Feb 2019 16:49:39 -0500 Message-ID: <345EDE69-C416-405F-B88C-04EE8384D20F@oracle.com> References: <631579E3-02F5-4E12-8BE6-DDAC0AE2E4A7@oracle.com> <549A6EB0-6E19-460D-9BE5-52AA40003AF0@intel.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "edwin.leung@oracle.com" To: "Wiles, Keith" Return-path: Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) by dpdk.org (Postfix) with ESMTP id 26B735F3C for ; Tue, 5 Feb 2019 22:49:42 +0100 (CET) In-Reply-To: <549A6EB0-6E19-460D-9BE5-52AA40003AF0@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" >=20 > Maybe I do not see the full problem here. If DPDK used poll instead of sel= ect it would solve the 1024 problem as poll has a high limit to the number o= f file descriptors at least that was my assumption.=20 >>=20 Thanks Keith.=20 The issue is not whether DPDK is using poll or select on the fd=E2=80=99s. The issue is that DPDK is raising the per-process number of fd=E2=80=99s abo= ve the maximum that glibc supports for select().=20 Therefore no other code within that process can reliably use select() on an f= d set, because any file that is opened may get an fd number > 1024.