From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x15LifwS015450; Tue, 5 Feb 2019 21:49:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=GHccHcRiguRLDZ0oxV+Htux/4rGF/yyMlHHjvZAAI74=; b=nPhU7P1zGIvA8p40yRB89wxqI3rtHUs/i+PR8lR3lsurN0z6/Yg/btMG9/Gz7IZjIcFr 6bXzq7B0zQh9fbIiex6O5DIR+WQcyiNo65ZGMA7VdllDB5/Okdf7MAg/WALtQma3K+AH IONzkYcYJVmPP3+7UdkTm92p08hAUnGChNClrrve/fe0PG9vvn56RzoNWsyekEaCm+Lk ZZrLvnnfalWnTyke6ifHKIkoCBWhpwkWHGPAlS3d3FtW86CGQY0KOWxChhAtl4zgPJca hF5FeEG3R0DhD2VQEP+PQAuC2sovkzbj0811fO43ObX3ftSCEUaSVirIfbfQycMA5L9p fA== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2qd98n5rys-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 05 Feb 2019 21:49:42 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x15Lnf9g011595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 5 Feb 2019 21:49:41 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x15LnfwB010111; Tue, 5 Feb 2019 21:49:41 GMT Received: from [192.168.2.105] (/65.96.173.82) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Feb 2019 21:49:40 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Iain Barker X-Mailer: iPhone Mail (16C101) In-Reply-To: <549A6EB0-6E19-460D-9BE5-52AA40003AF0@intel.com> Date: Tue, 5 Feb 2019 16:49:39 -0500 Cc: "dev@dpdk.org" , "edwin.leung@oracle.com" Content-Transfer-Encoding: quoted-printable Message-Id: <345EDE69-C416-405F-B88C-04EE8384D20F@oracle.com> References: <631579E3-02F5-4E12-8BE6-DDAC0AE2E4A7@oracle.com> <549A6EB0-6E19-460D-9BE5-52AA40003AF0@intel.com> To: "Wiles, Keith" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9158 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902050160 Subject: Re: [dpdk-dev] Question about DPDK hugepage fd change 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: , X-List-Received-Date: Tue, 05 Feb 2019 21:49:43 -0000 >=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.