From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3B191A0546; Tue, 6 Apr 2021 13:24:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A583C40F35; Tue, 6 Apr 2021 13:24:09 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id B6E8B4067C for ; Tue, 6 Apr 2021 13:24:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617708247; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6DZ4yJZpfMaU67VS9X5WoDaXyeZCdQ7z/VQS1jNS3EM=; b=QM75ldM3FEf9GdBtv0l4W1pQsHWKfEixUbb+uvULZ3nYPTh4SmvCOScZw3x7AHRiCRuTb8 vJ4ZaWHn/MPkdPXchoEA/+ZOOy7g4jrXgkZeedixXCmBspqym9kRCg4YSsxTg2DPZLk32U 7Dku7U2QhemVrsySd3BLcSCVQlIqbx0= Received: from mail-vs1-f70.google.com (mail-vs1-f70.google.com [209.85.217.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-546-EzlB5vjsMMSpBuD9X9jy5g-1; Tue, 06 Apr 2021 07:24:03 -0400 X-MC-Unique: EzlB5vjsMMSpBuD9X9jy5g-1 Received: by mail-vs1-f70.google.com with SMTP id p25so2076090vsn.1 for ; Tue, 06 Apr 2021 04:24:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6DZ4yJZpfMaU67VS9X5WoDaXyeZCdQ7z/VQS1jNS3EM=; b=t79h32/Cll8VhIiLz/JSmAj+mB8IChK+oa2fMYz3/G7nvwXwB92yFg0vtZS2PBDpu9 5nTMkrI3UBEktRx7p7Ky/a9iBIee0nYPFzN0WXgEfJF+O3GgyNS0KGVkhHKcBfet1Iuf QUgfPkA6nDsec9xu2KxOaHCrvyNmK8O+/nrRZQhl4/LUCgiOtHY0Cp5F1eh2dMYhDjX6 G38TiikGXgUdqFavpUll+p5OQWihkCm4+AUSZ82QdIGWYEXQdRUhbKZbCL6c0+TDnpB1 30ZhU4bYz/nCuWefq+E0iwJEtd62+qw28CyogVA8E76CxdXj47A/BOUQeHBi5nSFdc6n hXqA== X-Gm-Message-State: AOAM5330YHTGPy2AlsPrMeNvtcCklMBQsjnzbr9xBaR/8+psEWJ8E1w+ u6PQ6EHb+8Jy4euQWAkH7dKPAjlqMGziJnyBY4dmkHHiOx/cX8M0jwMx4kWVfkeIR0EZrQExLqK s5thiHihFbxYFFOUELUw= X-Received: by 2002:ab0:e17:: with SMTP id g23mr9379684uak.87.1617708243093; Tue, 06 Apr 2021 04:24:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIXK7yVry1JJ6Z5OJDfC5N7rOB9fQrJrdcToHDxVUuDK+xumpr7wNleOH30Rrgx7O2cu7cMe8/t/qUynuITFA= X-Received: by 2002:ab0:e17:: with SMTP id g23mr9379675uak.87.1617708242877; Tue, 06 Apr 2021 04:24:02 -0700 (PDT) MIME-Version: 1.0 References: <20200420110953.959884-1-fengli@smartx.com> <20200420160705.1652aeae@Sovereign> In-Reply-To: From: David Marchand Date: Tue, 6 Apr 2021 13:23:51 +0200 Message-ID: To: Feng Li Cc: "Burakov, Anatoly" , Li Feng , Dmitry Kozlyuk , Bruce Richardson , dev , Kyle Zhang , Yang Fan Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] librte_eal: add APIs to speedup virt2iova/phys X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 Tue, Apr 6, 2021 at 12:40 PM Feng Li wrote: > > On Thu, Apr 1, 2021 at 6:39 PM Burakov, Anatoly > wrote: > > > > On 25-Mar-21 1:32 PM, David Marchand wrote: > > > Hello, > > > > > > On Mon, Apr 20, 2020 at 4:13 PM Li Feng wrote: > > >> > > >> Cool, thank you, Anatoly and Kozlyuk. > > >> > > >> I haven't found how Windows implements the rte_mem_virt2phy. > > >> > > >> Using an opaque structure pointer as the first argument is a good idea. > > > > > > I pinged about this patch status 6 months ago but got no reply. > > > Trying again in public. > > > > > > From the thread, I understand that at best it would have to be done differently. > > > > > > > I would agree with the latter. Like i said in my original response, the > > fd-less API's are already on the very of what's acceptable and in the > > perfect world we wouldn't have them in the first place, and i don't like > > the fact that they exist and would wholly discourage their use, mainly > > because of very confusing semantics of real physical address vs. DPDK's > > IOVA vs. user IOVA, and potential for errors due to trying to resolve an > > IOVA address of something that doesn't even have it. > > > > Given the above, I certainly don't like the idea of building on top of > > these API's. > > Got it. Let's drop it. I marked it as rejected in patchwork. Thanks. -- David Marchand