Hi,
SPDK has identified a regression with commit 64051bb1 (devargs: unify scratch
buffer storage). The issue seems to be with this part of the patch:
@@ -276,15 +287,8 @@ rte_devargs_insert(struct rte_devargs **da)
if (strcmp(listed_da->bus->name, (*da)->bus->name) == 0 &&
On 10/11/21, 5:55 AM, "Thomas Monjalon" wrote:
11/10/2021 08:58, Xia, Chenbo:
> From: Liu, Changpeng
> > Another issue raised by Jim Harris is that for distro packaged DPDK,
since
> > this option isn't enabled by default, this will not allow SPDK
> > to use the distro pac
Hi,
I’ve tracked down a regression in SPDK to DPDK commit a2833ecc5 (“mempool: fix
get objects from mempool with cache”).
Here’s an example that demonstrates the problem:
Allocate mempool with 2048 buffers and cache size 256.
Core 0 allocates 512 buffers. Mempool pulls 512 + 256 buffers from b
> On Feb 24, 2023, at 6:56 AM, Honnappa Nagarahalli
> wrote:
>
>
>
>> -Original Message-
>> From: Morten Brørup
>> Sent: Friday, February 24, 2023 6:13 AM
>> To: Harris, James R ; dev@dpdk.org
>> Subject: RE: Bug in rte_mempool_do_generi
> On Aug 30, 2022, at 8:09 AM, David Marchand wrote:
>
> On Mon, Aug 29, 2022 at 7:12 PM Walker, Benjamin
> 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 wo
> On Sep 23, 2022, at 12:13 AM, David Marchand
> wrote:
>
> On Thu, Sep 22, 2022 at 12:29 AM Harris, James R
> wrote:
>>
>>
>> So sticking with the internal header copies for now, this works fine
>> for LTS and non-LTS releases. What about stable
Adding Changpeng Liu from SPDK side.
On 10/4/21, 6:48 AM, "David Marchand" wrote:
On Thu, Sep 30, 2021 at 10:45 AM David Marchand
wrote:
> On Wed, Sep 29, 2021 at 9:38 AM Xia, Chenbo wrote:
> > @David, could you help me understand what is the compile error in
Fedora 31?
>
> On Jul 28, 2022, at 8:26 AM, David Marchand wrote:
>
> This is a PoC for hiding the rte_bus, rte_driver and rte_device objects.
> And mark associated driver only API as internal.
>
> A good amount of the patches are preparation work on rte_bus.h,
> rte_dev.h, rte_devargs.h and rte_eal.h head
On 3/25/19, 2:06 PM, "Howell, Seth" wrote:
Hello,
In SPDK, we use the rte_mempool struct for many internal structure
collections. The per-thread cache and ease of allocation of mempools are very
useful features.
Some of the collections we store in SPDK are pools of I/O buffe
-Original Message-
From: Varghese, Vipin
Sent: Monday, March 25, 2019 7:53 PM
To: Harris, James R ; Howell, Seth
; dev@dpdk.org
Subject: RE: Aligned rte_mempool for storage applications
Hi Seth,
If I may I would like to suggest and ask a query on the mempool alig
On 3/19/20, 5:54 AM, "David Marchand" wrote:
On Tue, Mar 10, 2020 at 10:32 AM Bruce Richardson
wrote:
>
> On Mon, Mar 09, 2020 at 03:00:25AM -0700, Jim Harris wrote:
> > If contigmem is not able to allocate all of the
> > requested buffers, it frees whatever buffers we
On 8/16/19, 12:56 AM, "Burakov, Anatoly" wrote:
> @@ -89,6 +96,65 @@ set_tsc_freq(void)
> eal_tsc_resolution_hz = freq;
> }
>
> +static void
> +set_tsc_freq_secondary(void)
> +{
> + struct rte_mp_msg mp_req;
> + struct rte_mp_re
On 8/16/19, 12:19 PM, "dev on behalf of Jim Harris" wrote:
rte_eal_init() is much faster in secondary processes since
hugepages don't need to be zeroed. But there's still
non-trivial delays in the timer subsystem initialization
due to the 100ms sleep used to calculate TSC hz.
> On Aug 20, 2019, at 6:13 AM, Burakov, Anatoly
> wrote:
>
>> On 16-Aug-19 1:13 PM, Jim Harris wrote:
>> The code checks both rte_mp_request_sync() return
>> code and that the number of messages in the reply
>> equals 1. If rte_mp_request_sync() succeeds but
>> there was more than one messag
On 10/14/19, 4:18 AM, "David Marchand" wrote:
On Fri, Aug 16, 2019 at 9:19 PM Jim Harris wrote:
>
> The code checks both rte_mp_request_sync() return
> code and that the number of messages in the reply
> equals 1. If rte_mp_request_sync() succeeds but
> there was more
> On Oct 14, 2019, at 7:47 AM, David Marchand wrote:
>
> On Mon, Oct 14, 2019 at 3:49 PM Harris, James R
> wrote:
>> On 10/14/19, 4:18 AM, "David Marchand" wrote:
>>
>>>On Fri, Aug 16, 2019 at 9:19 PM Jim Harris
>>> wrote:
>&g
On 9/23/19, 8:41 AM, "Yigit, Ferruh" wrote:
On 9/18/2019 2:12 PM, Maxime Coquelin wrote:
>
>
> On 8/20/19 11:37 AM, Jim Harris wrote:
>> This function is listed under EXPERIMENTAL in the
>> rte_vhost_version.map, so it needs to be marked
>> with __rte_experimental
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, August 11, 2016 12:05 AM
> To: users at dpdk.org; dev at dpdk.org; Gonzalez Monroy, Sergio; Richardson,
> Bruce
> Cc: Verkamp, Daniel
> Subject: Re: [dpdk-dev] [dpdk-users] rte
> -Original Message-
> From: Gonzalez Monroy, Sergio
> Sent: Tuesday, August 16, 2016 12:37 AM
> To: Harris, James R; Thomas Monjalon; users at dpdk.org; dev at dpdk.org;
> Richardson, Bruce
> Cc: Verkamp, Daniel
> Subject: Re: [dpdk-dev] [dpdk-users] rte_zmalloc()
Hi,
SPDK would like to use DPDK’s pkg-config files rather than rolling our own
linker arguments. I’m running into a couple of issues – one looks like a bug,
the other is not as clear.
First is the use of --as-needed
(https://github.com/DPDK/dpdk/commit/b98447077b0609750c10b84b7b2e7be0c8504fad
On 9/24/20, 2:27 AM, "Bruce Richardson" wrote:
On Wed, Sep 23, 2020 at 07:21:16PM +0100, Harris, James R wrote:
>Hi,
>
>
>SPDK would like to use DPDK’s pkg-config files rather than rolling our
>own linker arguments. I’m runnin
On 10/7/20, 8:06 AM, "Thomas Monjalon" wrote:
Hi Jim,
Sorry I see nobody reviewed your patch.
Jim Harris wrote:
> + memcpy(&dev2->id, &dev->id, sizeof(dev2->id));
[...]
> + memcmp(&dev2->id, &dev->id, sizeof(dev2->id)))
Why using memcpy and memcmp instead of sim
Hello,
On 29/09/20 01:15 +, Niu, Yawei wrote:
>
>
> On 2020/9/28, 11:44 PM, "Harris, James R"
wrote:
>
> Hi Niu,
>
> I agree, this doesn't look right. Could you file an SPDK issu
23 matches
Mail list logo
