> From: David Marchand
>
> Hello,
>
> On Fri, Aug 5, 2022 at 1:19 AM Harris, James R
> wrote:
> > Can we keep rte_pci_register(), or a new variation of it that keeps
> > the rte_pci_driver structure hidden? Hiding rte_pci_register() would
> > mean SPDK can no longer work with a packaged DPDK.
> From: Thomas Monjalon
> Yes I think we need to agree on functions to keep as-is for compatibility.
> Waiting for your input please.
We've added a task to our backlog to propose a stable ABI for out of tree
drivers here. It's not as simple as just keeping a couple of the existing
functions -
> From: Thomas Monjalon
>
> In order to be perfectly clear, all the changes done around this option
> enable_driver_sdk share the goal of tidying stuff in DPDK so that ABI becomes
> better manageable.
> I think that nobody want to annoy the SPDK project.
> I understand that the changes effectivel
> From: Thomas Monjalon
> 12/10/2021 18:59, Walker, Benjamin:
> > For networking drivers, maybe. But certainly years and years ago when SPDK
> was started no one recommended putting an nvme driver into DPDK.
>
> No one from SPDK project proposed such thing.
> I asked sev
> From: dev On Behalf Of Thomas Monjalon
>
> 12/10/2021 02:35, Harris, James R:
> > On 10/11/21, 5:55 AM, "Thomas Monjalon" wrote:
> >
> > The meson option enable_driver_sdk is described as "Install headers to
> > build
> drivers."
> > Standard development packages should provide heade
On Mon, 2019-06-03 at 12:48 +0200, David Marchand wrote:
> Hello,
>
> On Thu, May 30, 2019 at 7:48 PM Ben Walker wrote:
> > In SPDK, not all drivers are registered with DPDK at start up time.
> > Previously, that meant DPDK always chose to set itself up in IOVA_PA
> > mode. Instead, when the cor
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Thursday, May 30, 2019 10:57 AM
> To: Walker, Benjamin
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 02/12] eal/pci: Inline several functions into
> rte_pci_get_iommu_clas
On Wed, 2019-01-30 at 16:27 +, Kevin Traynor wrote:
> Hi all,
>
> Here is a list of patches targeted for stable release 18.08.1. Please
> help review and test. The tentative date for the final release is 28,
> February. Before that, please shout if anyone has objections with these
> patches be
On Fri, 2017-12-22 at 09:13 +, Burakov, Anatoly wrote:
> On 21-Dec-17 9:38 PM, Walker, Benjamin wrote:
> > SPDK will need some way to register for a notification when pages are
> > allocated
> > or freed. For storage, the number of requests per second is (relative to
&
On Tue, 2017-12-19 at 11:14 +, Anatoly Burakov wrote:
>
> Quick outline of all changes done as part of this patchset:
>
> * Malloc heap adjusted to handle holes in address space
> * Single memseg list replaced by multiple expandable memseg lists
> * VA space for hugepages is preallocated
On Tue, 2017-11-28 at 14:16 +, Alejandro Lucero wrote:
>
>
> On Mon, Nov 27, 2017 at 5:58 PM, Walker, Benjamin
> wrote:
> > On Sun, 2017-11-05 at 01:17 +0100, Thomas Monjalon wrote:
> > > Hi, restarting an old topic,
> > >
> > > 05/01/2017 16:5
On Sun, 2017-11-05 at 01:17 +0100, Thomas Monjalon wrote:
> Hi, restarting an old topic,
>
> 05/01/2017 16:52, Tan, Jianfeng:
> > On 1/5/2017 5:34 AM, Walker, Benjamin wrote:
> > > > > Note that this
> > > > > probably means that using uio on recent
On Wed, 2017-01-04 at 11:11 +0100, Thomas Monjalon wrote:
> 2017-01-03 22:50, Walker, Benjamin:
> > 1) Physical addresses cannot be exposed to unprivileged users due to
> > security
> > concerns (the fallout of rowhammer). Therefore, systems without an IOMMU can
> > on
On Wed, 2017-01-04 at 19:39 +0800, Tan, Jianfeng wrote:
> Hi Benjamin,
>
>
> On 12/30/2016 4:41 AM, Walker, Benjamin wrote:
> > DPDK today begins by allocating all of the required
> > hugepages, then finds all of the physical addresses for
> > those hugepages using
gt; On Thu, 29 Dec 2016 20:41:21 +
> > > "Walker, Benjamin" wrote:
> > > > My second question is whether the user should be allowed to
> > > > mix uio and vfio usage simultaneously. For vfio, the
> > > > physical addresses are really DMA
Hi all,
I've been digging in to what it would take to run DPDK as an
unprivileged user and I have some findings that I thought
were worthy of discussion. The assumptions here are that I'm
using a very recent Linux kernel (4.8.15 to be specific) and
I'm using vfio with my IOMMU enabled. I'm only in
On Thu, 2016-12-01 at 11:56 +0530, Shreyansh Jain wrote:
> Hello Ben,
>
> On Thursday 24 November 2016 01:37 AM, Ben Walker wrote:
> >
> > Instead of passing domain, bus, devid, func, just pass
> > an rte_pci_addr.
> >
> > Signed-off-by: Ben Walker
> > ---
> > lib/librte_eal/linuxapp/eal/eal_p
Hi all,
My name is Ben Walker and I'm the technical lead for SPDK (it's like DPDK, but
for storage devices). SPDK relies on DPDK only for the base functionality in the
EAL - memory management, the rings, and the PCI scanning code. A key feature for
storage devices is support for hot insert and rem
On Mon, 2016-05-16 at 16:57 +, Wiles, Keith wrote:
> >
> > There is no inverse of rte_mempool_create, so this patch adds one.
> > The typical usage of rte_mempool_create is to create a pool at
> > initialization time and only to free it upon program exit, so an
> > rte_mempool_free function at
19 matches
Mail list logo
