From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by dpdk.org (Postfix) with ESMTP id 2EFD893C0 for ; Tue, 2 Feb 2016 06:50:38 +0100 (CET) Received: by mail-ob0-f175.google.com with SMTP id xk3so40322486obc.2 for ; Mon, 01 Feb 2016 21:50:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+k/8G8qnuOUSXqWWc0aQDVURuPkn5vmXqbYnu+DOeg0=; b=KHhC+5xFFbZgpT+dZKzO+obZXD0y+7h/vr44iB4S8SeMf3egbN99O7GN2vAvvk7+5B 5wLb2+FBkHVKFolgYVq9gwAnVkgR6DBZeJPcb/11UGQL8+57NWVi8UdAYz+B4yOAr+ze t/AqE/dlJfv1AE3u9mdSJyH+dqD6pno1VzNXLVGfnAUt35bfiy1DH/hS31Ln0yFHQo8k 2IcrUVtVjX4AKJO3cQF7rVPVb3nbsDpDMrxGuVDNr7CMA2Ojs4cJ03FwjIj1GWqWcReX in+9HgFjnf0ivNui5GYPGiAMmObkih5ZCYts16PQIjCsSjEbbOoASVZiwVmUpSe2rD1b tdxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+k/8G8qnuOUSXqWWc0aQDVURuPkn5vmXqbYnu+DOeg0=; b=YH8ELcNO3Mky+sQGAXfHvSztHdVxKP9KyQGT7KAMrkER+U9eA5GuIjVJBIk2XnSPp0 1zUEIhxAnYP3iH2Ntux0t9x668Vqev6RMGVsD5PSAhdKgmIn+QlAVTIWv6uW3TUW5T0D lXDwMneZ4pTT+AFgqBw+Bc7EawKCKWK00ekKtXw3zGsnUkKoVr/sgvvyrEGWKe6cfnPZ GGOw/IbPbv91tBEfh174ATy/7jpnYMZjy5pbu6nxPSTuHum3XywgxGREKetEqaZ4tCnY 4QAPEhZ+P0p5JkXusEh0WPWSLVcxgPPnOgYrWtXvPPELWTG/+w5ZyxnqD2+t1UW65Jhb tHfA== X-Gm-Message-State: AG10YORFfAuvCc1AhSXZMpGjT1/3I98aGFepi5acShBpfbP9yFxPbb3K86f1owVmzhWE/4a14ZT9YHR3cwgfU8tF X-Received: by 10.60.246.37 with SMTP id xt5mr12107614oec.72.1454392237649; Mon, 01 Feb 2016 21:50:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.180.72 with HTTP; Mon, 1 Feb 2016 21:50:18 -0800 (PST) In-Reply-To: <20160202054345.GI4257@yliu-dev.sh.intel.com> References: <1454091717-32251-1-git-send-email-sshukla@mvista.com> <20160201134854.GE4257@yliu-dev.sh.intel.com> <20160202054345.GI4257@yliu-dev.sh.intel.com> From: David Marchand Date: Tue, 2 Feb 2016 06:50:18 +0100 Message-ID: To: Yuanhan Liu Content-Type: text/plain; charset=UTF-8 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 05:50:38 -0000 On Tue, Feb 2, 2016 at 6:43 AM, Yuanhan Liu wrote: > On Tue, Feb 02, 2016 at 09:44:14AM +0530, Santosh Shukla wrote: >> Current use-case is virtio: It is used as io_bar which is first >> bar[1]. But implementation is generic, can be used to do rd/wr for >> other bar index too. Also vfio facilitate user to do rd/wr to pci_bars >> w/o mapping that bar, So apis will be useful for such cases in future. >> >> AFAIU: uio has read/write_config api only and Yes if bar region mapped >> then no need to do rd/wr, user can directly access the pci_memory. But >> use-case of this api entirely different: unmapped memory by >> application context i.e.. vfio_rd/wr-way {pread/pwrite-way}. >> >> Is above explanation convincing? Pl. let me know. > > TBH, not really. So, as you stated, it should be generic APIs to > read/write bar space, but limiting it to VFIO only and claiming > that read/write bar space is not support by other drivers (such > as UIO) while in fact it can (in some ways) doesn't seem right > to me. > > Anyway, it's just some thoughts from me. David, comments? >>From the very start, same opinion. We should have a unique api to access those, and eal should hide details like kernel drivers (uio, vfio, whatever) to the pmd. Now the thing is, how to do this in an elegant and efficient way. Regard, -- David Marchand