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 99C59A00E6 for ; Thu, 11 Jul 2019 18:21:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1277C322C; Thu, 11 Jul 2019 18:21:57 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id AFC8631FC for ; Thu, 11 Jul 2019 18:21:55 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2019 09:21:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,479,1557212400"; d="scan'208";a="168070165" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.10]) ([10.237.221.10]) by fmsmga007.fm.intel.com with ESMTP; 11 Jul 2019 09:21:53 -0700 To: Jerin Jacob Kollanukkaran , Vamsi Krishna Attunuru , "dev@dpdk.org" Cc: "olivier.matz@6wind.com" , "arybchenko@solarflare.com" , "Burakov, Anatoly" References: <20190422061533.17538-1-kirankumark@marvell.com> <20190625035700.2953-1-vattunuru@marvell.com> <51e1b2c8-4290-c9b5-701f-5be55e763425@intel.com> <4906aad7-47a2-6707-cf69-417043c46c8c@intel.com> <7bfd30cf-aec6-9fd3-00b0-ed8964849869@intel.com> From: Ferruh Yigit Openpgp: preference=signencrypt Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJUBBMBCgA+AhsDAh4BAheABQkI71rKFiEE 0jZTh0IuwoTjmYHH+TPrQ98TYR8FAlznMMQFCwkIBwMFFQoJCAsFFgIDAQAACgkQ+TPrQ98T YR/B9Q//a57esjq996nfZVm7AsUl7zbvhN+Ojity25ib2gcSVVsAN2j6lcQS4hf6/OVvRj3q CgebJ4o2gXR6X12UzWBJL7NE8Xpc70MvUIe0r11ykurQ9n9jUaWMjxdSqBPF93hU+Z/MZe5M 1rW5O2VJLuTJzkDw3EYUCbHOwPjeaS8Qqj3RI0LYbGthbHBIp9CsjkgsJSjTT5GQ8AQWkE7I z+hvPx6f1rllfjxFyi4DI3jLhAI+j1Nm+l+ESyoX59HrLTHAvq4RPkLpTnGBj9gOnJ+5sVEr GE0fcffsNcuMSkpqSEoJCPAHmChoLgezskhhsy0BiU3xlSIj1Dx2XMDerUXFOK3ftlbYNRte HQy4EKubfZRB8H5Rvcpksom3fRBDcJT8zw+PTH14htRApU9f8I/RamQ7Ujks7KuaB7JX5QaG gMjfPzHGYX9PfF6KIchaFmAWLytIP1t0ht8LpJkjtvUCSQZ2VxpCXwKyUzPDIF3co3tp90o7 X07uiC5ymX0K0+Owqs6zeslLY6DMxNdt8ye+h1TVkSZ5g4dCs4C/aiEF230+luL1CnejOv/K /s1iSbXQzJNM7be3FlRUz4FdwsfKiJJF7xYALSBnSvEB04R7I2P2V9Zpudkq6DRT6HZjBeJ1 pBF2J655cdoenPBIeimjnnh4K7YZBzwOLJf2c6u76fe5Ag0EV9ZMvgEQAKc0Db17xNqtSwEv mfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ESYpV8QWj0xK4YM0dLxnDU2IYxjEshSB1T qAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4AibPtrHuIXWQOBECcVZTTOdZYGAzaYzxiA ONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxDUQljeNvKYt1lZE/gAUUxNLWsYyTT+22/ vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35p iVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVjsM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQ I3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdcq9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYH fVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH71PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZ qw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFBVOQOxCvwRG2QCgcJ/UTn5vlivul+cThi 6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJl Rr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYCGwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNh HwUCXOcvZgUJBvIWKAAKCRD5M+tD3xNhHxhBD/9toXMIaPIVFd9w1nKsRDM1GE6gZe4jie8q MJpeHB9O+936fSXA0W2X0het60wJQQ45O8TpTcxpc9nGzcE4MTaLAI3E8TjIXAO0cPqUNLyp g0DXezmTw5BU+SKZ51+jSKOtFmzJCHOJZQaMeCHD+G3CrdUHQVQBb5AeuH3KFv9ltgDcWsc8 YO70o3+tGHwcEnyXLdrI0q05wV7ncnLdkgVo+VUN4092bNMPwYly1TZWcU3Jw5gczOUEfTY7 sgo6E/sGX3B+FzgIs5t4yi1XOweCAQ/mPnb6uFeNENEFyGKyMG1HtjwBqnftbiFO3qitEIUY xWGQH23oKscv7i9lT0gg2D+ktzZhVWwHJVY/2vWSB9aCSWChcH2BT+lWrkwSpoPhy+almM84 Qz2wF72/d4ce4L27pSrS+vOXtXHLGOOGcAn8yr9TV0kM4aR+NbGBRXGKhG6w4lY54uNd9IBa ARIPUhij5JSygxZCBaJKo+X64AHGkk5bXq+f0anwAMNuJXbYC/lz4DEdKmPgQGShOWNs1Y1a N3cI87Hun/RBVwQ0a3Tr1g6OWJ6xK8cYbMcoR8NZ7L9ALMeJeuUDQR39+fEeHg/6sQN0P0mv 0sL+//BAJphCzDk8ztbrFw+JaPtgzZpRSM6JhxnY+YMAsatJRXA0WSpYP5zzl7yu/GZJIgsv VQ== Message-ID: Date: Thu, 11 Jul 2019 17:21:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 7/4/2019 10:48 AM, Jerin Jacob Kollanukkaran wrote: >> From: Vamsi Krishna Attunuru >> 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 ; Burakov, Anatoly >> Subject: Re: [dpdk-dev] [PATCH v6 0/4] add IOVA = 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 there be case that new flag functionality would fail  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 for > Mempool objects has nearly zero overhead. But I leave decision to maintainers. > >> 2) Adding 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 IOVA_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 I support the idea to remove 'kni' forcing to the IOVA=PA mode, but also not sure about forcing all KNI users to update their code to allocate mempool in a very specific way. What about giving more control to the user on this? Any user want to use IOVA=VA and KNI together can update application to justify memory allocation of the KNI and give an explicit "kni iova_mode=1" config. Who want to use existing KNI implementation can continue to use it with IOVA=PA mode which is current case, or for this case user may need to force the DPDK application to IOVA=PA but at least there is a workaround. And kni sample application should have sample for both case, although this increases the testing and maintenance cost, I hope we can get support from you on the iova_mode=1 usecase. What do you think? > >> >> Can someone suggest if any changes required to address above issues. > ________________________________________ > From: dev on behalf of Vamsi Krishna Attunuru > 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:arybchenko@solarflare.com > Subject: [EXT] Re: [dpdk-dev] [PATCH v6 0/4] add IOVA = VA support in KNI >   > 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:arybchenko@solarflare.com > Subject: RE: [dpdk-dev] [PATCH v6 0/4] add IOVA = VA support in KNI > >> -----Original Message----- >> From: Burakov, Anatoly >> Sent: Tuesday, June 25, 2019 7:09 PM >> To: Jerin Jacob Kollanukkaran ; Vamsi Krishna Attunuru >> ; 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 = 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 On Behalf Of Burakov, Anatoly >>>>> Sent: Tuesday, June 25, 2019 3:30 PM >>>>> To: Vamsi Krishna Attunuru ; 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 = VA support in KNI >>>>> >>>>> On 25-Jun-19 4:56 AM, mailto:vattunuru@marvell.com wrote: >>>>>> From: Vamsi Attunuru >>>>>> >>>>>> ---- >>>>>> 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 = 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 = 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 = 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 packets >> 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 to > Skip the page boundaries? > > All, > Either option is fine, Asking for feedback to processed further? >