01/07/2024 11:27, Ruifeng Wang:
>
> On 2024/6/28 11:22 AM, Yutang Jiang wrote:
> > The AmpereOneAC04 is efficient Cloud Native CPU:
> >Up to 192 Cores
> >2MB Private L2 Cache per Core
> >8 channel DDR5
> >128 lanes PCIe Gen5
> >
> > Signed-off-by: Yutang Jiang
>
> Acked-by: Ruif
On 2024/6/28 11:22 AM, Yutang Jiang wrote:
The AmpereOneAC04 is efficient Cloud Native CPU:
Up to 192 Cores
2MB Private L2 Cache per Core
8 channel DDR5
128 lanes PCIe Gen5
Signed-off-by: Yutang Jiang
---
config/arm/arm64_ampereoneac04_linux_gcc | 17 +
config/a
The AmpereOneAC04 is efficient Cloud Native CPU:
Up to 192 Cores
2MB Private L2 Cache per Core
8 channel DDR5
128 lanes PCIe Gen5
Signed-off-by: Yutang Jiang
---
config/arm/arm64_ampereoneac04_linux_gcc | 17 +
config/arm/meson.build | 19 +++
onnappa.nagaraha...@arm.com
> Subject: [DPDK][PATCH v4] config/arm: add Ampere AmpereOneAC04
> platform
>
> The AmpereOneAC04 is efficient Cloud Native CPU:
> Up to 192 Cores
> 2MB Private L2 Cache per Core
> 8 channel DDR5
> 128 lanes PCIe Gen5
&g
Advantech ICVG x86 Software
02-7732-3399 Ext. 1249
-Original Message-
From: Ferruh Yigit
Sent: Monday, May 27, 2024 4:58 PM
To: Jack.Chen ; dev@dpdk.org
Cc: Amy.Shih ; bill.lu ;
Jenny3.Lin ; Bruce Richardson
; Mcnamara, John
Subject: Re: DPDK patch for Amston Lake SGMII <> GPY215
; dev@dpdk.org
> Cc: Amy.Shih ; bill.lu ;
> Jenny3.Lin ; Bruce Richardson
> ; Mcnamara, John
> Subject: Re: DPDK patch for Amston Lake SGMII <> GPY215
>
> On 5/24/2024 6:40 AM, Jack.Chen wrote:
>> Dear DPDK Dev .
>>
>> This is PM from Advantech ENPD. We
On 5/24/2024 6:40 AM, Jack.Chen wrote:
> Dear DPDK Dev .
>
> This is PM from Advantech ENPD. We are working on Intel Amston Lake
> CPU’s SGMII <> GPY215 PHY for DPDK test but fail.
>
> We consulted with Intel support team and they suggested we should
> consult DPDK community and it should have t
Dear DPDK Dev .
This is PM from Advantech ENPD. We are working on Intel Amston Lake CPU's
SGMII <> GPY215 PHY for DPDK test but fail.
We consulted with Intel support team and they suggested we should consult DPDK
community and it should have the patch or code change for Amston Lake <> GYP215
av
4 PM
> *To:* Deng, KaiwenX ; dev@dpdk.org
> *Cc:* Amiya Ranjan Mohakud ; Amiya
> Ranjan Mohakud
> *Subject:* Regarding
> https://mails.dpdk.org/archives/dev/2023-June/270558.html dpdk patch
>
>
>
> Hi Kaiwenx
>
>
>
> I came across the below DPDK iavf error messag
Hi Kaiwenx
I came across the below DPDK iavf error message during the initialization
of X710 NICs in ESX. It seems the functionality works fine, but with below
error messages.
DPDK Version: 22.11.2
2023-12-08T09:58:00.901 |9322| MSG [NET] dpdk_port_configure:1717
Configure port eth3/1. lsc_
dpdk patch
Hi Kaiwenx
I came across the below DPDK iavf error message during the initialization of
X710 NICs in ESX. It seems the functionality works fine, but with below error
messages.
DPDK Version: 22.11.2
2023-12-08T09:58:00.901 |9322| MSG [NET] dpdk_port_configure:1717
Configure
On 26-09-2023 17:04, Aaron Conole wrote:
Okay - we typically don't use pull requests. If you and others are are
okay, I can take the patches and repost them to the ML from the pull
requests with a note indicating such.
Yes please; that would be helpful.
Thanks, John
John Romein writes:
> Dear Elena, Aaron,
Hi John,
> I hope you had a nice time after the DPDK workshop.
>
> I was unable to solve the issues with our mailserver to submit a patch
> with git sendmail. So I created a pull request:
> https://github.com/DPDK/dpdk/pull/69
> @Elena, could you plea
Dear Elena, Aaron,
I hope you had a nice time after the DPDK workshop.
I was unable to solve the issues with our mailserver to submit a patch
with git sendmail. So I created a pull request:
https://github.com/DPDK/dpdk/pull/69
@Elena, could you please handle the pull request? I will submit a
07/04/2022 16:51, Marcin Danilewicz:
> Added changes after review and increased throughput.
>
> Signed-off-by: Marcin Danilewicz
I think these changes should be squashed with the first patch.
You need to version your patches also:
this one should have been v2, next one should be v3.
And while a
> -Original Message-
> From: Marcin Danilewicz
> Sent: Thursday, April 7, 2022 3:52 PM
> To: dev@dpdk.org
> Cc: Ajmera, Megha
> Subject: [dpdk][PATCH 1/2] sched: enable/disable TC OV at runtime
>
> From: Megha Ajmera
>
> Added new API to enable or di
Added changes after review and increased throughput.
Signed-off-by: Marcin Danilewicz
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index 1d05089d00..6e7d81df46 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -155,7 +155,6 @@ struct rte_sched_subport {
uint
From: Megha Ajmera
Added new API to enable or disable TC over subscription for best
effort traffic class at subport level.
By default TC OV is disabled for subport.
Signed-off-by: Megha Ajmera
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index ec74bee939..1d05089d00 100644
--- a
r/dpdk-stable/commit/b466dfc9a5e3c486c43421a5a072bae7a777e720
https://github.com/kevintraynor/dpdk-stable/commit/ae6979cd9c13e47704da99cbdcb14ad5a38fb4ff
Thanks,
Honnappa
-Original Message-
From: DPDK patchwork
Sent: Tuesday, March 8, 2022 3:40 AM
To: Honnappa Nagarahalli
Subject: [dpdk] P
From: DPDK patchwork
Sent: Tuesday, March 8, 2022 3:40 AM
To: Honnappa Nagarahalli
Subject: [dpdk] Patch notification: 2 patches updated
Hello,
The following patches (submitted by you) have been updated in Patchwork:
* dpdk: [v3,1/2] examples/l3fwd: use single set of variables throughout
03/08/2021 15:19, fengchengwen:
> On 2021/8/3 20:59, Thomas Monjalon wrote:
> > 03/08/2021 14:54, fengchengwen:
> >> Hi, Thomas
> >>
> >> Why the dmadev patchset v12/13 both deferred ? Does it have anything to do
> >> with
> >> the completion of 21.08?
> >
> > We are fixing the last critical bugs
On 2021/8/3 20:59, Thomas Monjalon wrote:
> 03/08/2021 14:54, fengchengwen:
>> Hi, Thomas
>>
>> Why the dmadev patchset v12/13 both deferred ? Does it have anything to do
>> with
>> the completion of 21.08?
>
> We are fixing the last critical bugs to close 21.08 this week.
> We don't accept new f
03/08/2021 14:54, fengchengwen:
> Hi, Thomas
>
> Why the dmadev patchset v12/13 both deferred ? Does it have anything to do
> with
> the completion of 21.08?
We are fixing the last critical bugs to close 21.08 this week.
We don't accept new features.
What did you expect?
Do you understand that
Hi, Thomas
Why the dmadev patchset v12/13 both deferred ? Does it have anything to do with
the completion of 21.08?
Thanks
Forwarded Message
Subject: [dpdk] Patch notification: 6 patches updated
Date: Tue, 3 Aug 2021 12:20:03 +
From: DPDK patchwork
To: fengcheng
Hi,
Pls don't use fixline if your patch code doesn't merged in community.
> -Original Message-
> From: Pei, Andy
> Sent: Tuesday, January 15, 2019 13:38
> To: dev@dpdk.org
> Cc: Xu, Rosen ; Zhang, Tianfei
> ; Pei, Andy
> Subject: [DPDK] [PATCH v4] raw/if
fix a typo and delete code of unused function
Fixes: 88c9eb7cb4b5 (\"fix a typo and delete code of unused function\")
Cc: andy@intel.com
Cc: rosen...@intel.com
Cc: tianfei.zh...@intel.com
Signed-off-by: Andy Pei
---
drivers/raw/ifpga_rawdev/base/opae_hw_api.c | 24 +---
> -Original Message-
> From: Burakov, Anatoly
> Sent: Friday, August 25, 2017 10:31 AM
> To: dev@dpdk.org
> Cc: Griffin, John ; Trahe, Fiona
> ; Jain, Deepak K ; De
> Lara Guarch, Pablo ; Burakov, Anatoly
>
> Subject: [DPDK] [PATCH 1/3] qat: remove atomics
From: "Burakov, Anatoly"
Don't write CSR tail until we processed enough TX descriptors.
To avoid crypto operations sitting in the TX ring indefinitely,
the "force write" threshold is used:
- on TX, no tail write coalescing will occur if number of inflights
is below force write threshold
- o
From: "Burakov, Anatoly"
Replacing atomics in the qat driver with simple 16-bit integers for
number of inflight packets.
This adds a new limitation to the QAT driver: each queue pair is
now explicitly single-threaded.
Signed-off-by: Burakov, Anatoly
---
doc/guides/cryptodevs/qat.rst
From: "Burakov, Anatoly"
Don't write CSR head until we processed enough RX descriptors.
Also delay marking them as free until we are writing CSR head.
Signed-off-by: Burakov, Anatoly
---
doc/guides/rel_notes/release_17_11.rst | 1 +
drivers/crypto/qat/qat_crypto.c| 49
2015-10-21 10:41, Matthew Hall:
> On Wed, Oct 21, 2015 at 11:03:41AM +0200, Thomas Monjalon wrote:
> > Compilation must be tested with GCC and clang, as static and shared
> > libraries
> > and for 32-bit and 64-bit targets.
>
> Is this process scripted somewhere?
Yes, I've sent a script:
On 2015/10/21 17:05, Thomas Monjalon wrote:
> 2015-10-21 11:48, Panu Matilainen:
>> On 10/21/2015 11:25 AM, Thomas Monjalon wrote:
>>> 2015-10-20 21:34, Stephen Hemminger:
Patch backlog is not getting better, now at 486.
How can we break this logjam?
Do I need to make a new "rea
On 2015/10/16 22:25, Neil Horman wrote:
> On Fri, Oct 16, 2015 at 10:45:23AM +0200, Thomas Monjalon wrote:
>> 2015-10-15 14:44, Stephen Hemminger:
>>> There are currently 428 patches in New state in DPDK patchwork.
>>>
>>> Thomas, could you start reducing that backlog?
>> Yes
>>
>>> The simplest so
On 10/21/2015 11:25 AM, Thomas Monjalon wrote:
> 2015-10-20 21:34, Stephen Hemminger:
>> Patch backlog is not getting better, now at 486.
>>
>> How can we break this logjam?
>> Do I need to make a new "ready for merge" tree?
>
> What would mean "ready for merge"?
> A lot of patches are acked but do
2015-10-21 11:48, Panu Matilainen:
> On 10/21/2015 11:25 AM, Thomas Monjalon wrote:
> > 2015-10-20 21:34, Stephen Hemminger:
> >> Patch backlog is not getting better, now at 486.
> >>
> >> How can we break this logjam?
> >> Do I need to make a new "ready for merge" tree?
> >
> > What would mean "re
On Wed, Oct 21, 2015 at 11:03:41AM +0200, Thomas Monjalon wrote:
> Compilation must be tested with GCC and clang, as static and shared libraries
> and for 32-bit and 64-bit targets.
Is this process scripted somewhere?
Matthew.
2015-10-20 21:34, Stephen Hemminger:
> Patch backlog is not getting better, now at 486.
>
> How can we break this logjam?
> Do I need to make a new "ready for merge" tree?
What would mean "ready for merge"?
A lot of patches are acked but do not compile or doc is missing.
I have the feeling it wo
On Wed, Oct 21, 2015 at 10:25:12AM +0200, Thomas Monjalon wrote:
> 2015-10-20 21:34, Stephen Hemminger:
> > Patch backlog is not getting better, now at 486.
> >
> > How can we break this logjam?
> > Do I need to make a new "ready for merge" tree?
>
> What would mean "ready for merge"?
> A lot of
Patch backlog is not getting better, now at 486.
How can we break this logjam?
Do I need to make a new "ready for merge" tree?
Hi Hemminger,
+1
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhu, Heqing
> Sent: Friday, October 16, 2015 10:47 AM
> To: Stephen Hemminger; Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] DPDK patch backlog
>
&g
2015-10-15 14:44, Stephen Hemminger:
> There are currently 428 patches in New state in DPDK patchwork.
>
> Thomas, could you start reducing that backlog?
Yes
> The simplest solution would be to merge some of the big patch series
> from Intel for the base drivers, then reviewers can focus on the
On Fri, Oct 16, 2015 at 10:45:23AM +0200, Thomas Monjalon wrote:
> 2015-10-15 14:44, Stephen Hemminger:
> > There are currently 428 patches in New state in DPDK patchwork.
> >
> > Thomas, could you start reducing that backlog?
>
> Yes
>
> > The simplest solution would be to merge some of the big
+1
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger
Sent: Friday, October 16, 2015 5:44 AM
To: Thomas Monjalon
Cc: dev at dpdk.org
Subject: [dpdk-dev] DPDK patch backlog
There are currently 428 patches in New state in DPDK patchwork.
Thomas
There are currently 428 patches in New state in DPDK patchwork.
Thomas, could you start reducing that backlog?
The simplest solution would be to merge some of the big patch series
from Intel for the base drivers, then reviewers can focus on the other
patches.
44 matches
Mail list logo
