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 BD126A0471 for ; Tue, 16 Jul 2019 12:07:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C3E183798; Tue, 16 Jul 2019 12:07:30 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 1EEC03423 for ; Tue, 16 Jul 2019 12:07:29 +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 x6GA4qFJ018152; Tue, 16 Jul 2019 03:07:28 -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=xEu3WvVYfvD6gKR19N4TFBU39k5ckYRsG6/Pmbg/Jd8=; b=FlTo5lJKyntDDyBpGaykChBlKjl7blUeWo77bjuSAttJCA8PSKSDLlP/GjSKoGof3K4j aosIGoWaQSnSF6EBRHwty+pImuRN9JVXYT9fA3tw+yavYch9jQCD5SgSA01OwDkzyEoB haK4vJnaXHIIjQ3cJBEzB3xoT5MiyXX558RHN+/U9Gd2aChMzBtsrT6eZnCTgvlGtyzb uqhfGUhenLMvTRMbcIABdNeJDMH/hSmkfJPVrfUezoAnp5U8wZuZiqFWLz8/rMto+B3n DAp6pBMOQtHaBRipyGM9nCNxH/EO/3+6yCsLyYZfDgBwSImt9lytd+ANhlevvQ27JwJT 7w== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 2ts0a22jq9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 16 Jul 2019 03:07:27 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 16 Jul 2019 03:07:26 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.57) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 16 Jul 2019 03:07:26 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lg/1Z6AqvgOaNIGAv9OG4PuAmRGqQQCjioZRfZfKIgzLK00yFK2u+yUADi4dJpiBMCUEtbZFcsunvXdfNTVQkNGTnM8Ub+gh3Buka7f5mASwKv6A4vxD50JYVFR4o1ZSytiuzIHaMQwV7XrgCEdYhr80T0k+nIqmck1ZugXTC8Nz+xrFmk24HHqAorZWKdFevDENSfbLA8PaTvrhZG43ZbM7YdXVDjRHE2yXYU4HjKO1AscqfnKm7w2V/gay4SQP7Q+eshyiuPRy0cn2j2J+Q5/BCf3Zc7Hq4lHc/s1DoX5Dzv4uujjAtdg0qGCRfcRlOiVSfgf2mRDmYmG3RCa79A== 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=xEu3WvVYfvD6gKR19N4TFBU39k5ckYRsG6/Pmbg/Jd8=; b=GcM6e8vhwGoWD/f+W+YyYz1zJDcnqH9KhfGTo0ZBxQ04gUEBlozjP7ny9Gnjp9puAJclrzEvzRV1Bw3v7CB/ANWDbHOtIdJ0//Ht0qFJEhrvUSk4LYeaVGrsgulcduUIdhWdyKnHbgYIFz0lUfw1myUgm8cTdtu5xF59tkDT06ovEFdZH23jb50TK+B4dxLG32E0CJnf4dGpeW2F8SsZCHrgwnSUhghlQ2O47sovQBNpATpsG+mL7kTSNlX5vLw9BO5n7y+Q0YasLjvgUYm1L0+O+HFjJpxwfW94egukTAfFe6RuJdm1+ehfFWI96aDMpJkP0nD/hZK99ZUuqw/3Xg== 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=xEu3WvVYfvD6gKR19N4TFBU39k5ckYRsG6/Pmbg/Jd8=; b=K1oBFSh6auWy0ulURPh3dtyxB2qxaZzscN3w5PelKMtjaZS7b9WpAzZcDMnVMqeuls5uJQ4f5z6GX2mgf8hK4uGBudG0IJeqTeeybY2NN16lSZVbdcc8H0fVe6UjWIpH7BJwwd5ACYfz9WcPU+HPAVgBfQVaHMu2CkpYvfOyywQ= Received: from CH2PR18MB3381.namprd18.prod.outlook.com (52.132.246.204) by CH2PR18MB3190.namprd18.prod.outlook.com (52.132.247.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Tue, 16 Jul 2019 10:07:21 +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 10:07:21 +0000 From: Vamsi Krishna Attunuru To: Olivier Matz CC: "Burakov, Anatoly" , 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+abLbKeAgAGDyYCAAAnlIIAACVMAgAABVyA= Date: Tue, 16 Jul 2019 10:07:21 +0000 Message-ID: References: <0ef0c75d-bff6-ac20-61e1-a4a2472fc7f7@intel.com> <20190716084649.snqtibua7i4zvsum@platinum> <20190716095536.cc2yve3bpkkw2dgd@platinum> In-Reply-To: <20190716095536.cc2yve3bpkkw2dgd@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: 928793bf-924f-4999-d621-08d709d56487 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:CH2PR18MB3190; x-ms-traffictypediagnostic: CH2PR18MB3190: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0100732B76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(366004)(396003)(136003)(13464003)(189003)(199004)(51444003)(6246003)(53936002)(3846002)(6116002)(14454004)(8676002)(6506007)(76176011)(2906002)(316002)(9686003)(81156014)(99286004)(8936002)(7696005)(54906003)(55236004)(74316002)(26005)(186003)(102836004)(81166006)(305945005)(4326008)(478600001)(7736002)(229853002)(53546011)(256004)(55016002)(486006)(6916009)(476003)(11346002)(446003)(66946007)(76116006)(25786009)(68736007)(66066001)(66476007)(66556008)(71190400001)(66446008)(71200400001)(6436002)(64756008)(52536014)(33656002)(5660300002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:CH2PR18MB3190; 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: XdnZK4kev83Wc4IZHv+w+42DRYJ/nQLD7+XjpUXCYtTGA2bdruMUgo5qFoG5lnEpYCOdrldJUh7j8tW1RY2zWt2fbITILiQ8cC4EsIRmUkiveKIZnbBeEEUCkN+BpCW0YF1ADi9zFFIwXE0mCP9x0oyVpjUnqlH6Wipwha05zbY6BezMscQAI2hGZwEvTfro9GIqYcK9MJBvvx1dxqu50cLbISJco7mMdly5NhXKKVOAFGf7VhXvvLTDRbxzIUo4Or+95MKloOFwvYEWEVoHVOc7fcHeQNjZhcmDhTeYunwfHkxi5EK7EUiPImsnTjAAnOOd1YSmxehzvq2xb196vQD/A0bIy6yYr16noYLlBQFTwSYhCSmLebXwTqNhCB0Cqthm8mC1/KVcoKwIlwIQxVI/uuhxX27Llr2llKMAjj0= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 928793bf-924f-4999-d621-08d709d56487 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2019 10:07:21.2264 (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: CH2PR18MB3190 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 3:26 PM > To: Vamsi Krishna Attunuru > Cc: Burakov, Anatoly ; Jerin Jacob Kollanukkar= an > ; Ferruh Yigit ; 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 Tue, Jul 16, 2019 at 09:40:59AM +0000, Vamsi Krishna Attunuru wrote: > > > > > > > -----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 > > > > > > Hi, > > > > > > 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= need > 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. > > > > > > Sorry for the late feedback. > > > > > > I think we can change the default behavior of mempool populate(), to > > > prevent objects from being accross 2 pages, except if the size of > > > the object is bigger 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. > > > > > > This would avoid the introduction of a specific API to allocate > > > packets for kni, and a specific mempool flag. > > > > > > 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)" ? > > > > > > > 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 by default in rte_mempool_populate_default() and later it can be > > cleared based on obj_per_page in rte_mempool_op_calc_mem_size_default()= . > I do not see specific requirement of these flag apart from handling above > sequence. >=20 > Sorry, I don't get why you want to keep this flag. Is it to facilitate th= e error check > in kni code? Yes, it's only for error check I thought. >=20 > The flags are used by the mempool user to ask for a specific behavior, so= if we > change the default behavior, there is nothing to change to the user API. Correct, the flags are meant for mempool users. As you suggested there is n= o requirement of new APIs or flags by changing default behavior. >=20 > > 2) For problems of 9k mbuf, I think that check could be addressed in kn= i lib(in > rte_kni_init and return error). >=20 > You can use rte_mempool_obj_iter() to iterate the objects (mbufs) in the > mempool, to ensure that none of them is accross 2 pages.