From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id BD005A0471 for ; Tue, 16 Jul 2019 11:41:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 539253798; Tue, 16 Jul 2019 11:41:08 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id CE0303195 for ; Tue, 16 Jul 2019 11:41:06 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6G9f1Uk026580; Tue, 16 Jul 2019 02:41:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=6rlZbmDARuCRtRFehxaYJuY52aWJFuE9BXsL4pTtYxg=; b=lllgz3DCRtJ2m02Tln7e8Dp/tBEIQYVeGvMrnpOFYeo9jllHzJTXM9mqrgHvLfxYlRr8 gdoeTJLpralbmVEhtifLiDzYytdwU+rnEwDghbr03YcGJFC1uPGhiccgXkHNIumBtYcE GSWhWrk0iZ9+jFVG2NDqjRxbMo7gbWkdMupriRAeKBX5xsYCWyOyBDnwO7r5Fhy3qssl mapJrvrEAIPnsti/M9cDZ78BJA+eSA1hydAmB1RbsdGWPD5bC/Pyd3kePnKoozjNJq6V K9uS2TmLMmLkJQVUBnvl5cNXXG1L/Jnl5JuWMOPA8krxp9uA/k7BDK7i1/MhWR+mntAE Dg== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 2ts0a22fqy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 16 Jul 2019 02:41:05 -0700 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 16 Jul 2019 02:41:04 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.59) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 16 Jul 2019 02:41:04 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PkecIbQQG8eAGZ5AQxUxhXxnCaXleOdyrZeZVNdE+QL7sVNffrM0BwWwNa2rV+jZLIityGXN7LVutq6wTxfNHsfsTZfENrkGK79Fv1gE1bvFRN6E/SpClAN16Yb4s+G3zwSp+RLVUYrN4Db1AMZaAnlb832qtkIfhAGgEFvyr3sld+Aq3uR1QkL1hKyuROTloUZTbMP/4C4TmbAkq+xg4meOCjUKAcBAXHWT6KVB8fFWYXVjSDbF8H/I4gLOeuuUTcaVBWTWz4jilvn+USwzcjdFWNdQQGrpgbrVUnJKWAZ8MDIA7tbhOaoF7+5npZDt5cz6T4ewZbFuubCxsT+hFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6rlZbmDARuCRtRFehxaYJuY52aWJFuE9BXsL4pTtYxg=; b=dKi2Z9gHTI5zLvR93ZvB3ToTkOm1vWC8f/iI3yoFBo6kN1/jPEGkoH40HxlD5zN0cQT/O0w54qN/JAcjnNLVCdcRloqQPqy99+Ltv6MIW+tsNlN+x7sm6UAJ2th49c+Nsg3Buq3xlzQYiDwQAC1bNSRbV56hIDdjjQ0BGyD2izbFber841XFfbspqWbjHJHowPu/0QYoPaqy2j9HuspDQyz4eeOju4Lbtw0pn/7x+rKIp0bpBMljRj/ow3tj7SEezEeJ0WRVr1QfowpnOyqANFTp4rfbywBgq8Ovb6N8mm3hLrcMOhU/A7sq/0BhZ8+Dd9fczqMo+64Rz15cLotKuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=marvell.com;dmarc=pass action=none header.from=marvell.com;dkim=pass header.d=marvell.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6rlZbmDARuCRtRFehxaYJuY52aWJFuE9BXsL4pTtYxg=; b=xWMLY7ibvxAQ9EGq0VO+GZo1ZMMdcMChFgLYeBe+FIIERt4+xaL86Z5xLzaRCygYNqCpI4GoatcXMeQKxIG4kb6IJsLOaRnGxeGMEG7KNnI8wF3IrYPpp28v1iu39+RaJYtACSpnYce1+t8D1d1p+vel63EsncBi0ote68m9MGA= Received: from CH2PR18MB3381.namprd18.prod.outlook.com (52.132.246.204) by CH2PR18MB3335.namprd18.prod.outlook.com (52.132.246.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Tue, 16 Jul 2019 09:40:59 +0000 Received: from CH2PR18MB3381.namprd18.prod.outlook.com ([fe80::189c:3889:b207:8922]) by CH2PR18MB3381.namprd18.prod.outlook.com ([fe80::189c:3889:b207:8922%5]) with mapi id 15.20.2073.012; Tue, 16 Jul 2019 09:40:59 +0000 From: Vamsi Krishna Attunuru To: Olivier Matz , "Burakov, Anatoly" CC: Jerin Jacob Kollanukkaran , Ferruh Yigit , "dev@dpdk.org" , "arybchenko@solarflare.com" Thread-Topic: [dpdk-dev] [EXT] Re: [PATCH v6 0/4] add IOVA = VA support in KNI Thread-Index: AQHVOslVIQpJUBKAmUeySf0qtzZs+abLbKeAgAGDyYCAAAnlIA== Date: Tue, 16 Jul 2019 09:40:59 +0000 Message-ID: References: <0ef0c75d-bff6-ac20-61e1-a4a2472fc7f7@intel.com> <20190716084649.snqtibua7i4zvsum@platinum> In-Reply-To: <20190716084649.snqtibua7i4zvsum@platinum> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [14.140.231.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 58cab8fc-94fa-482c-693f-08d709d1b5b9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CH2PR18MB3335; x-ms-traffictypediagnostic: CH2PR18MB3335: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0100732B76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(39860400002)(136003)(366004)(396003)(51444003)(189003)(199004)(13464003)(33656002)(66946007)(66066001)(7736002)(64756008)(66446008)(305945005)(66556008)(66476007)(86362001)(6246003)(81156014)(81166006)(55016002)(8936002)(9686003)(478600001)(71200400001)(71190400001)(6436002)(74316002)(52536014)(2906002)(53936002)(5660300002)(25786009)(68736007)(11346002)(446003)(256004)(476003)(316002)(76176011)(99286004)(186003)(26005)(6506007)(53546011)(3846002)(6116002)(102836004)(55236004)(14454004)(8676002)(486006)(76116006)(4326008)(110136005)(229853002)(54906003)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:CH2PR18MB3335; H:CH2PR18MB3381.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /caPzpM2DMCV7ciKdjT7nJC+3a/B1w3b7/9toND/uL0fFznZXy3m54TzxBdacg8YZh5LE0iRSSq+f0kzihKgqhVhihobCb1gx3daitEao/9rrbHbyuzdgJX53vBMRfZCYZ8eFUU6B7YoJS0fu6MsIgHItD3G+ftz/c7XHK4v9xod1tzQUfW3UFREbSQfjHKs2Y1+RmcwShtdWOPJhmlq0VITHOpo4NvK/zTqm25B9YsCCnW8WEnw9JPLiLjyHVC6jQZkOohwiUyCJH1tod+gRS+Hop7eWf+O/z01Pfgin8nG0STn2Qhlm6o74BguyDjLz/+hG7fD3PdyExRhxri5cI5tD6OiGleUPjfLynDk2wo6IgLnK5ZWT2gPIExx6nylQ7u3iUepfjnWH0aL/tISkuzQOyMq78WjnlZSfZfPeHk= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 58cab8fc-94fa-482c-693f-08d709d1b5b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2019 09:40:59.6667 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vattunuru@marvell.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR18MB3335 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-16_02:2019-07-16,2019-07-16 signatures=0 Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v6 0/4] add IOVA = VA support in KNI 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Olivier Matz > Sent: Tuesday, July 16, 2019 2:17 PM > To: Burakov, Anatoly > Cc: Jerin Jacob Kollanukkaran ; Ferruh Yigit > ; Vamsi Krishna Attunuru ; > dev@dpdk.org; arybchenko@solarflare.com > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v6 0/4] add IOVA =3D VA support = in KNI >=20 > Hi, >=20 > On Mon, Jul 15, 2019 at 10:38:53AM +0100, Burakov, Anatoly wrote: > > On 15-Jul-19 5:54 AM, Jerin Jacob Kollanukkaran wrote: > > > > > > > > > (also, i don't really like the name NO_PAGE_BOUND since > > > > > > > > > in memzone API there's a "bounded memzone" allocation > > > > > > > > > API, and this flag's name reads like objects would not > > > > > > > > > be bounded by page size, not that they won't cross page > > > > > > > > > boundary) > > > > > > > > > > > > > > > > No strong opinion for the name. What name you suggest? > > > > > > > > > > > > > > How about something like MEMPOOL_F_NO_PAGE_SPLIT? > > > > > > > > > > > > Looks good to me. > > > > > > > > > > > > In summary, Change wrt existing patch" > > > > > > - Change NO_PAGE_BOUND to MEMPOOL_F_NO_PAGE_SPLIT > > > > > > - Set this flag in rte_pktmbuf_pool_create () when > > > > > rte_eal_has_hugepages() || > > > > > > rte_malloc_heap_socket_is_external(socket_id)) > > > > > > > > > > If we are to have a special KNI allocation API, would we even nee= d that? > > > > > > > > Not need this change in rte_pktmbuf_pool_create () if we introduce > > > > a new rte_kni_pktmbuf_pool_create () API. > > > > > > Ferruh, Olivier, Anatoly, > > > > > > Any objection to create new rte_kni_pktmbuf_pool_create () API to > > > embedded MEMPOOL_F_NO_PAGE_SPLIT flag requirement for KNI + IOVA > as > > > VA > > > > > > > > > > As long as we all are aware of what that means and agree with that > > consequence (namely, separate codepaths for KNI and other PMD's) then > > i have no specific objections. >=20 > Sorry for the late feedback. >=20 > I think we can change the default behavior of mempool populate(), to prev= ent > objects from being accross 2 pages, except if the size of the object is b= igger than > the size of the page. This is already what is done in > rte_mempool_op_calc_mem_size_default() when we want to estimate the > amount of memory needed to allocate N objects. >=20 > This would avoid the introduction of a specific API to allocate packets f= or kni, > and a specific mempool flag. >=20 > About the problem of 9K mbuf mentionned by Anatoly, could we imagine a > check in kni code, that just returns an error "does not work with > size(mbuf) > size(page)" ? >=20 Yes, change in default behavior avoids new APIs or flags. Two minor changes on top of above suggestions. 1) Can flag(NO_PAGE_SPLIT) be retained.?, sequence is like, flag is set b= y default in rte_mempool_populate_default() and later it can be cleared based on obj_per_page in rte_mempool_op_calc_me= m_size_default(). I do not see specific requirement of these flag apart from handling above sequence. 2) For problems of 9k mbuf, I think that check could be addressed in kni li= b(in rte_kni_init and return error). > Thanks, > Olivier