From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 36A76A0487
	for <public@inbox.dpdk.org>; Thu,  4 Jul 2019 11:48:51 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id F117D1B9AC;
	Thu,  4 Jul 2019 11:48:50 +0200 (CEST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com
 [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 9E7FD1B9A7
 for <dev@dpdk.org>; Thu,  4 Jul 2019 11:48:49 +0200 (CEST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1])
 by mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id
 x649ji6V030670; Thu, 4 Jul 2019 02:48:48 -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=NFfeJuOAx8lvjk6vhW60erKQ1ia7eeeeoj+GR1ebrNM=;
 b=pX4+MEvH8qA98m1Vb/YHz4Za+jg1AkviAvKBPpobJjjcUr3YN+1oBGWOXoAD9rbzW5nT
 pg/QeSgVpkp0rQYsD9wvLIq1TeBfCNowwezT6r8nuwsdqxdDdPJS4KewUteQqvkA0A5n
 he/0CtODqNy98Fa7hpweazOjz8OuXzPrA61P+QL6uiT36wzJeudaBSnwFLLB6eOHPC92
 oiNdpY0YkCLf9SjDUvzueKF+iJwSuKXssaN6nAb97sOLNiZuox6i3nxs9A3K5dHlT6TI
 koTOieTT0nYvAAUY82hatNH4NCWBf0XhsP2rbt1Y6o6pcB5E7KtKe3Xfs1hoGH4gfMs7 hw== 
Received: from sc-exch04.marvell.com ([199.233.58.184])
 by mx0b-0016f401.pphosted.com with ESMTP id 2tgtf74vh5-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT);
 Thu, 04 Jul 2019 02:48:48 -0700
Received: from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH04.marvell.com
 (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 4 Jul
 2019 02:48:46 -0700
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.56) by
 SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server
 (TLS) id
 15.0.1367.3 via Frontend Transport; Thu, 4 Jul 2019 02:48:46 -0700
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=NFfeJuOAx8lvjk6vhW60erKQ1ia7eeeeoj+GR1ebrNM=;
 b=fWUJnCoNznwiX8Wi7JDsfyU5rMDow39DegTSxLBppPP81UPaD0aPrGyjB+83fNB2LUNnjrA4MCah7TW5gVTdUSTdPfsLMMugzh4EF7iKiQIcN6pNIG3J8IPiF8cpesTW2YyLuqclgi7caATZYl1GDiLZGBp92FNGCPNDcwRSdCk=
Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by
 BYAPR18MB2758.namprd18.prod.outlook.com (20.179.56.224) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2052.18; Thu, 4 Jul 2019 09:48:44 +0000
Received: from BYAPR18MB2424.namprd18.prod.outlook.com
 ([fe80::2d42:12b6:aa2e:2862]) by BYAPR18MB2424.namprd18.prod.outlook.com
 ([fe80::2d42:12b6:aa2e:2862%4]) with mapi id 15.20.2032.019; Thu, 4 Jul 2019
 09:48:44 +0000
From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
To: Vamsi Krishna Attunuru <vattunuru@marvell.com>, "dev@dpdk.org"
 <dev@dpdk.org>
CC: "ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
 "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
 "arybchenko@solarflare.com" <arybchenko@solarflare.com>, "Burakov, Anatoly"
 <anatoly.burakov@intel.com>
Thread-Topic: [dpdk-dev] [PATCH v6 0/4] add IOVA = VA support in KNI
Thread-Index: AQHVKwoafNHW4TJ9wE2nxOtOpOT2SaasI4eAgAASfBCAAAatAIAAI9CAgALfuRCABpHUAIAEP0yAgAAwRyA=
Date: Thu, 4 Jul 2019 09:48:43 +0000
Message-ID: <BYAPR18MB24248C01D322B23624F5A4B0C8FA0@BYAPR18MB2424.namprd18.prod.outlook.com>
References: <20190422061533.17538-1-kirankumark@marvell.com>
 <20190625035700.2953-1-vattunuru@marvell.com>
 <51e1b2c8-4290-c9b5-701f-5be55e763425@intel.com>
 <BYAPR18MB2424BD439E0E064A9A2A0B05C8E30@BYAPR18MB2424.namprd18.prod.outlook.com>
 <4906aad7-47a2-6707-cf69-417043c46c8c@intel.com>
 <7bfd30cf-aec6-9fd3-00b0-ed8964849869@intel.com>,
 <BYAPR18MB2424AEDB7DC683B72499409FC8FD0@BYAPR18MB2424.namprd18.prod.outlook.com>,
 <CH2PR18MB3381B54DCC3266E718BBFF16A6F90@CH2PR18MB3381.namprd18.prod.outlook.com>
 <CH2PR18MB338114A210A8240CA689788BA6FA0@CH2PR18MB3381.namprd18.prod.outlook.com>
In-Reply-To: <CH2PR18MB338114A210A8240CA689788BA6FA0@CH2PR18MB3381.namprd18.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [106.200.248.176]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d91cb3bb-cdf6-413a-2e91-08d70064cd92
x-microsoft-antispam: BCL:0; PCL:0;
 RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020);
 SRVR:BYAPR18MB2758; 
x-ms-traffictypediagnostic: BYAPR18MB2758:
x-microsoft-antispam-prvs: <BYAPR18MB275874A92884CEC38AC7BE46C8FA0@BYAPR18MB2758.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0088C92887
x-forefront-antispam-report: SFV:NSPM;
 SFS:(10009020)(4636009)(39860400002)(136003)(376002)(366004)(396003)(346002)(199004)(13464003)(189003)(53754006)(486006)(52536014)(14454004)(25786009)(256004)(478600001)(54906003)(14444005)(66446008)(6116002)(3846002)(68736007)(64756008)(66476007)(316002)(66556008)(66946007)(5660300002)(76116006)(110136005)(2501003)(73956011)(66066001)(6436002)(186003)(6506007)(55016002)(53546011)(476003)(7736002)(9686003)(33656002)(102836004)(26005)(229853002)(11346002)(2906002)(446003)(8676002)(7696005)(86362001)(8936002)(4326008)(71190400001)(71200400001)(74316002)(81166006)(81156014)(76176011)(53936002)(99286004)(305945005)(6246003);
 DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2758;
 H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en;
 PTR:InfoNoRecords; A:1; MX: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: yByVzmr4floFV7GGIRDRM3mSC71M8AMU1VoVbXMdJoiwjl12iks/huGmpGg4E2ihNAOlB3j38GMP1qcaqtr6hosoDa6aEYfRz5koQkd08EakK+BFjuPzTQ2F/sn6Zw2yWS57vLk722VO4dmEqg8hYCm07WbICfleeFOjMUzOjfksZJ1GtF/7WPCZVpSY7HxYE2TjVHD94FC+qQOkg1iIekOFVciyAIPTlqSTS+wc3/4+STgNdPF3XHpd9qdK6+StIcL8eOgY9Z3UA1fmQu927yjwHTWB+5V6hKA1CSsT1IjiBoNpG9G7ddY5au30AlAhfATNRiGw19e96lQUjPMq9JgkmYxECE1Ny/6hEF/HNLLypD4evpKk/AxaY+G+FGRy5vxF2IfR0HdrO/6WuGLirLxhyhG9HOF80Z8y7MR/fkI=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d91cb3bb-cdf6-413a-2e91-08d70064cd92
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2019 09:48:43.9934 (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: jerinj@marvell.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2758
X-OriginatorOrg: marvell.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, ,
 definitions=2019-07-04_06:, , signatures=0
Subject: Re: [dpdk-dev] [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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

>From: Vamsi Krishna Attunuru=20
>Sent: Thursday, July 4, 2019 12:13 PM
>To: dev@dpdk.org
>Cc: ferruh.yigit@intel.com; olivier.matz@6wind.com; arybchenko@solarflare.=
com; Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Burakov, Anatoly <anat=
oly.burakov@intel.com>
>Subject: Re: [dpdk-dev] [PATCH v6 0/4] add IOVA =3D VA support in KNI
>
>Hi All,
>
>Just to summarize, below items have arisen from the initial review.
>1) Can the new mempool flag be made default to all the pools and will ther=
e be case that new flag functionality would fail=A0 for some page sizes.?

If the minimum huge page size is 2MB and normal huge page size is 512MB or =
1G. So I think, new flags can be default as skipping the page boundaries fo=
r=20
Mempool objects has nearly zero overhead. But I leave decision to maintaine=
rs.

>2)=A0Adding HW device info(pci dev info) to KNI device structure, will it =
break KNI on virtual devices in VA or PA mode.?

Iommu_domain will be created only for PCI devices and the system runs in IO=
VA_VA mode. Virtual devices(IOVA_DC(don't care) or
IOVA_PA devices still it works without PCI device structure)

It is  a useful feature where KNI can run without root privilege and it is =
pending for long time. Request to review and close this

>
>Can someone suggest if any changes required to address above issues.=20
________________________________________
From: dev <mailto:dev-bounces@dpdk.org> on behalf of Vamsi Krishna Attunuru=
 <mailto:vattunuru@marvell.com>
Sent: Monday, July 1, 2019 7:21:22 PM
To: Jerin Jacob Kollanukkaran; Burakov, Anatoly; mailto:dev@dpdk.org
Cc: mailto:ferruh.yigit@intel.com; mailto:olivier.matz@6wind.com; mailto:ar=
ybchenko@solarflare.com
Subject: [EXT] Re: [dpdk-dev] [PATCH v6 0/4] add IOVA =3D VA support in KNI=
=20
=A0
External Email

----------------------------------------------------------------------
ping..

________________________________
From: Jerin Jacob Kollanukkaran
Sent: Thursday, June 27, 2019 3:04:58 PM
To: Burakov, Anatoly; Vamsi Krishna Attunuru; mailto:dev@dpdk.org
Cc: mailto:ferruh.yigit@intel.com; mailto:olivier.matz@6wind.com; mailto:ar=
ybchenko@solarflare.com
Subject: RE: [dpdk-dev] [PATCH v6 0/4] add IOVA =3D VA support in KNI

> -----Original Message-----
> From: Burakov, Anatoly <mailto:anatoly.burakov@intel.com>
> Sent: Tuesday, June 25, 2019 7:09 PM
> To: Jerin Jacob Kollanukkaran <mailto:jerinj@marvell.com>; Vamsi Krishna =
Attunuru
> <mailto:vattunuru@marvell.com>; mailto:dev@dpdk.org
> Cc: mailto:ferruh.yigit@intel.com; mailto:olivier.matz@6wind.com;
> mailto:arybchenko@solarflare.com
> Subject: Re: [dpdk-dev] [PATCH v6 0/4] add IOVA =3D VA support in KNI
>
> On 25-Jun-19 12:30 PM, Burakov, Anatoly wrote:
> > On 25-Jun-19 12:15 PM, Jerin Jacob Kollanukkaran wrote:
> >>> -----Original Message-----
> >>> From: dev <mailto:dev-bounces@dpdk.org> On Behalf Of Burakov, Anatoly
> >>> Sent: Tuesday, June 25, 2019 3:30 PM
> >>> To: Vamsi Krishna Attunuru <mailto:vattunuru@marvell.com>; mailto:dev=
@dpdk.org
> >>> Cc: mailto:ferruh.yigit@intel.com; mailto:olivier.matz@6wind.com;
> >>> mailto:arybchenko@solarflare.com
> >>> Subject: Re: [dpdk-dev] [PATCH v6 0/4] add IOVA =3D VA support in KNI
> >>>
> >>> On 25-Jun-19 4:56 AM, mailto:vattunuru@marvell.com wrote:
> >>>> From: Vamsi Attunuru <mailto:vattunuru@marvell.com>
> >>>>
> >>>> ----
> >>>> V6 Changes:
> >>>> * Added new mempool flag to ensure mbuf memory is not scattered
> >>>> across page boundaries.
> >>>> * Added KNI kernel module required PCI device information.
> >>>> * Modified KNI example application to create mempool with new
> >>>> mempool flag.
> >>>>
> >>> Others can chime in, but my 2 cents: this reduces the usefulness of
> >>> KNI because it limits the kinds of mempools one can use them with,
> >>> and makes it so that the code that works with every other PMD
> >>> requires changes to work with KNI.
> >>
> >> # One option to make this flag as default only for packet mempool(not
> >> allow allocate on page boundary).
> >> In real world the overhead will be very minimal considering Huge page
> >> size is 1G or 512M # Enable this flag explicitly only IOVA =3D VA mode
> >> in library. Not need to expose to application # I don't think, there
> >> needs to be any PMD specific change to make KNI with IOVA =3D VA mode =
#
> >> No preference on flags to be passed by application vs in library.
> >> But IMO this change would be
> >> needed in mempool support KNI in IOVA =3D VA mode.
> >>
> >
> > I would be OK to just make it default behavior to not cross page
> > boundaries when allocating buffers. This would solve the problem for
> > KNI and for any other use case that would rely on PA-contiguous
> > buffers in face of IOVA as VA mode.
> >
> > We could also add a flag to explicitly allow page crossing without
> > also making mbufs IOVA-non-contiguous, but i'm not sure if there are
> > use cases that would benefit from this.
>
> On another thought, such a default would break 4K pages in case for packe=
ts
> bigger than page size (i.e. jumbo frames). Should we care?

The hugepage size will not be 4K. Right?

Olivier,

As a maintainer any thoughts of exposing/not exposing the new mepool flag t=
o
Skip the page boundaries?

All,
Either option is fine, Asking for feedback to processed further?