From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <arybchenko@solarflare.com> Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id C44A74C7F for <dev@dpdk.org>; Mon, 5 Mar 2018 10:16:14 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id C590AB40053; Mon, 5 Mar 2018 09:16:07 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 5 Mar 2018 09:15:58 +0000 To: "Burakov, Anatoly" <anatoly.burakov@intel.com>, <dev@dpdk.org> CC: Thomas Monjalon <thomas@monjalon.net>, <keith.wiles@intel.com>, <jianfeng.tan@intel.com>, <andras.kovacs@ericsson.com>, <laszlo.vadkeri@ericsson.com>, <benjamin.walker@intel.com>, <bruce.richardson@intel.com>, <konstantin.ananyev@intel.com>, <kuralamudhan.ramakrishnan@intel.com>, <louise.m.daly@intel.com>, <nelio.laranjeiro@6wind.com>, <yskoh@mellanox.com>, <pepperjo@japf.ch>, <jerin.jacob@caviumnetworks.com>, <hemant.agrawal@nxp.com>, <olivier.matz@6wind.com> References: <cover.1520083504.git.anatoly.burakov@intel.com> <a43f6a900f8b9eeba981005dbb49fcc5c59778b7.1520083504.git.anatoly.burakov@intel.com> <405c4b97-4561-6ef7-5844-fdc0cdfaabc5@solarflare.com> <28a175c1-b306-ec7b-e69b-003b40968d2e@intel.com> From: Andrew Rybchenko <arybchenko@solarflare.com> Message-ID: <62f57c50-3e5a-7202-7a40-6d0e66c68b43@solarflare.com> Date: Mon, 5 Mar 2018 12:15:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <28a175c1-b306-ec7b-e69b-003b40968d2e@intel.com> Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23700.003 X-TM-AS-Result: No--4.215300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1520241374-qEy9adUpuKXQ Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 31/41] ethdev: use contiguous allocation for DMA memory 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://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 05 Mar 2018 09:16:15 -0000 On 03/05/2018 12:08 PM, Burakov, Anatoly wrote: > On 03-Mar-18 2:05 PM, Andrew Rybchenko wrote: >> On 03/03/2018 04:46 PM, Anatoly Burakov wrote: >>> This fixes the following drivers in one go: >> >> Does it mean that these drivers are broken in the middle of patch set >> and fixed now? >> If so, it would be good to avoid it. It breaks bisect. >> > > Depends on the definition of "broken". Legacy memory mode will still > work for all drivers throughout the patchset. As for new memory mode, > yes, it will be "broken in the middle of the patchset", but due to the > fact that there's enormous amount of code to review between fbarray > changes, malloc changes, contiguous allocation changes and adding new > rte_memzone API's, i favored ease of code review over bisect. > > I can of course reorder and roll up several different patchset and all > driver updates into one giant patch, but do you really want to be the > one reviewing such a patch? Is it possible to: 1. Introduce _contig function 2. Switch users of the contiguous allocation to it as you do now 3. Make the old function to allocate possibly non-contiguous memory