[AMD Official Use Only - AMD Internal Distribution Only]
Hi Thomas,
Please find the AMD EPYC testing results for both rc-1 and rc-2 shared below
RC-1:
- tuning guide: https://doc.dpdk.org/guides/linux_gsg/amd_platform.html
- OS: Ubuntu 24.04.2, 6.8.0
- Grub: default_hugepagesz=1GB isolcpus=7-63
[Public]
Hi Morten,
We have tested the effect of the patch using func-latency and PPs via testpmd.
Please find our observations below
- DPDK tag: 25.07-rc1
- compiler: gcc 14.2
- platform: AMD EPYC 8534P 64core 2.3GHz
- app cmd:
-- One port: ` sudo build/app/dpdk-testpmd -l 15,16 --vdev=n
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Stephen
> -Original Message-
> From: Stephen Hemminger
> Sent: Thursday, June 26, 2025 8:31 PM
> To: Varghese, Vipin
> Cc: dev@dpdk.org; David Marchand ;
> sta...@dpdk.org
> Subject: Re: [PATCH v3 1
[AMD Official Use Only - AMD Internal Distribution Only]
Hi David & Stephen,
> -Original Message-
> From: Stephen Hemminger
> Sent: Tuesday, June 17, 2025 8:30 PM
> To: dev@dpdk.org
> Cc: Stephen Hemminger ; sta...@dpdk.org
> Subject: [PATCH v3 1/2] latencystats: fix receive sample MP is
[Public]
> -Original Message-
> From: Stephen Hemminger
> Sent: Friday, June 13, 2025 6:04 AM
> To: dev@dpdk.org
> Cc: Stephen Hemminger
> Subject: [PATCH 0/2] Latencystat optimization and fix
>
> Caution: This message originated from an External Source. Use proper caution
> when opening
[Public]
> -Original Message-
> From: Bruce Richardson
> Sent: Thursday, June 12, 2025 3:49 PM
> To: Varghese, Vipin
> Cc: Anatoly Burakov ; dev@dpdk.org; Vladimir
> Medvedkin
> Subject: Re: [PATCH v6 23/33] net/ixgbe: create common Rx queue structure
>
[Public]
Hi Bruce & Anatoly,
We are facing an issue while apply patch 23 individually or series.
We get the following error for individual apply
```
$ git apply p23.patch --verbose
Checking patch drivers/net/intel/common/rx.h...
Checking patch drivers/net/intel/ixgbe/ixgbe_ethdev.c...
Checking
[Public]
> -Original Message-
> From: Bruce Richardson
> Sent: Wednesday, June 11, 2025 4:23 PM
> To: dev@dpdk.org
> Cc: Varghese, Vipin ; Bruce Richardson
>
> Subject: [PATCH v5] build: reduce use of AVX compiler flags
>
> Caution: This message originated f
[AMD Official Use Only - AMD Internal Distribution Only]
> -Original Message-
> From: Bruce Richardson
> Sent: Tuesday, June 10, 2025 8:37 PM
> To: Varghese, Vipin
> Cc: dev@dpdk.org; Song, Keesang
> Subject: Re: [PATCH v4] build: reduce use of AVX compiler flags
[Public]
Snipped
> >
> > In above log I get `2 instances of march`; logs `-march=native -mrtm
> > -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-
> truncation -Wno-address-of-packed-member -
> DRTE_LOG_DEFAULT_LOGTYPE=pmd.net.i40e -DCC_AVX512_SUPPORT -
> march=skylake-avx512`.
> >
> >
[Public]
Hi Bruce,
Snipped
> > > > >
> > > > > Hi Bruce, we have reviewed this internally and tested the same.
> > > > > We would like
> > > > your thought for the following.
> > > > >
> > > > > - Before patch: we were directly setting AVX512 falgs for F, BW,
> > > > > DQ, VL
> > > > > - new pat
[Public]
Snipped
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> 27/05/2025 17:29, Bruce Richardson:
> > This patchset performs some basic cleanup of EAL lcore arguments
> > before any more serious w
[AMD Official Use Only - AMD Internal Distribution Only]
> -Original Message-
> From: Bruce Richardson
> Sent: Monday, June 9, 2025 1:28 PM
> To: Varghese, Vipin
> Cc: dev@dpdk.org; Song, Keesang
> Subject: Re: [PATCH v4] build: reduce use of AVX compiler flags
[Public]
> -Original Message-
> From: Stephen Hemminger
> Sent: Monday, June 9, 2025 8:33 AM
> To: dev@dpdk.org
> Cc: Stephen Hemminger
> Subject: [RFC] doc: change recommendation for installation of tools on Fedora
>
> Caution: This message originated from an External Source. Use proper
[Public]
Snipped
>
>
> Hi Vipin,
>
> No need. Pavan fixed it already:
> https://patchwork.dpdk.org/project/dpdk/patch/20250520201726.7420-1-
> pbhagavat...@marvell.com/
Thank you
>
> -Morten
>
> > From: Varghese, Vipin [mailto:vipin.vargh...@amd.com]
[Public]
Snipped
>
>
> When doing a build for a target that already has the instruction sets for
> AVX2/AVX512 enabled, skip emitting the AVX compiler flags, or the
> skylake-avx512 '-march' flags, as they are unnecessary. Instead, when the
> default
> flags produce the desired output, just use
[Public]
Snipped
> >
> > A number of libs and drivers had special optimized AVX2 and AVX512
> > code paths for performance reasons, and these tended to have
> > copy-pasted logic to build those files. Centralise that logic in the
> > main drivers/ and lib/ meson.build files to avoid duplication.
[Public]
Snipped
> > > When freeing transmitted mbufs, there is no reason to send the freed
> > > mbufs directly to the ring if the cache is empty - only if it is
> > > zero size (in which case the cache pointer is NULL). Therefore,
> > > remove the empty check and only check for a null cache poi
[Public]
Hi Vanishka,
I believe you were trying to reach out using email id
`vipin.vargh...@intel.com`. Please use `vipin.vargh...@amd.com` as I no longer
have access to intel.com
Snipped
>
>
> From: Vinod Pullabhatla
>
> Add support to set Tx rate on DPAA platform through PMD APIs
>
> Sign
[Public]
Hi All,
Saring `rte_topology_` API patch next version targeted for upcoming release.
Extras adding support for Cache-ID for L2 and L3 for Cache line stashing, Code
Data Prioritization too.
Snipped
>
> >
> > Hello Vipin and others,
> >
> > please, will there be any progress or update o
t; > -Original Message-
> > From: Pavan Nikhilesh Bhagavatula
> > Sent: Monday, May 19, 2025 7:32 PM
> > To: Morten Brørup ; Varghese, Vipin
> >
> > Cc: dev
> > Subject: RE: rte_lcore_has_role() return value
> >
> > Hi Morten,
> >
[Public]
Snipped
> >
> > > > > > When doing a build for a target that already has the
> > > > > > instruction sets for AVX2/AVX512 enabled, skip emitting the
> > > > > > AVX compiler flags, or the
> > > > > > skylake-avx512 '-march' flags, as they are unnecessary.
> > > > > > Instead, when the de
[AMD Official Use Only - AMD Internal Distribution Only]
Snipped
>
> Hello Vipin and others,
>
> please, will there be any progress or update on this series?
Apologies, we did a small update in slack, and missed this out here. Let me try
to address your questions below
>
> I successfully teste
[Public]
Snipped
> > > > When doing a build for a target that already has the instruction
> > > > sets for AVX2/AVX512 enabled, skip emitting the AVX compiler
> > > > flags, or the
> > > > skylake-avx512 '-march' flags, as they are unnecessary. Instead,
> > > > when the default flags produce the
[Public]
Hi Morten,
snipped
>
>
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Thursday, 13 February 2025 09.34
> >
> > 13/02/2025 04:09, Varghese, Vipin:
> > > [AMD Official Use Only - AMD Internal Distribution Only]
> &g
[Public]
Hi Thomas
snipped
> >
> > Thomas and Ajith can we get some help to get this mainline too?
>
> Yes, sorry the review discussions did not start.
> It has been forgotten.
>
> You could rebase a v2 to make it more visible.
Sure will do this week.
>
> Minor note: the changelog should be aft
Domain (IO): at index (0) there are 48 core, with (0) at index 0
> - SNC=2
> Domain (IO): at index (0) there are 24 core, with (0) at index 0
> Domain (IO): at index (1) there are 24 core, with (12) at index 0
>
> 2. AMD EPYC 8534P:
> - NPS=1:
> Domain
>
> 20/03/2024 02:40, Vipin Varghese:
> > In case incorrect NUMA configuration, the current commit shares
> > 1) either `source or destination numa is greater`
> > 2) instead of `actual NUMA` it is `acture NUMA`
> > 3) uses `printf` instead of PRINT_ERR
> >
> > current patch changes the above t
[Public]
Snipped
>
>
> The current tap device is slow both due to architectural choices and the
> overhead of
> Linux system calls. I am exploring a how to fix that but some of the choices
> require
> some tradeoffs. Which leads to some open questions:
>
> 1. DPDK tap also support tunnel (TUN) m
Snipped
> > >
> > > I recall from the Cache Stashing community call... There is some
> > > ACPI
> > function to
> > > get the (opaque) "location IDs" of various parts in the system, to
> > > be
> > used for setting
> > > the Cache Stashing hints.
> > > Is there only one "ACPI location ID" (I don't
Snipped
>
>
> > > > > Does the API need to be prepared for L4 cache?
> > > > > https://www.anandtech.com/show/16924/did-ibm-just-preview-the-
> > future
> > > > > -
> > > > of-caches
> > > > Thank you for the pointer, yes initial patch was considering L4
> > cache
> > > > too. But I was not able
Snipped
>
> > > Does the API need to be prepared for L4 cache?
> > > https://www.anandtech.com/show/16924/did-ibm-just-preview-the-future
> > > -
> > of-caches
> > Thank you for the pointer, yes initial patch was considering L4 cache
> > too. But I was not able to get hold of system or get someo
Snipped
>
> Does the API need to be prepared for L4 cache?
> https://www.anandtech.com/show/16924/did-ibm-just-preview-the-future-of-caches
Thank you for the pointer, yes initial patch was considering L4 cache too. But
I was not able to get hold of system or get someone to test this with L4.
Hen
Snipped
>
> > +struct topology_config {
> > +#ifdef RTE_EAL_HWLOC_TOPOLOGY_PROBE
> > + hwloc_topology_t topology;
> > +#endif
> > +
> > + /* domain count */
> > + uint16_t l1_count;
> > + uint16_t l2_count;
> > + uint8_t l3_count;
> > + uint8_t io_count;
> > +
> > + /*
Snipped
>
> > + /* domain count */
> > + uint16_t l1_count;
> > + uint16_t l2_count;
> > + uint8_t l3_count;
> > + uint8_t io_count;
>
> Make them all uint16_t, the space is there already.
Thank you, fixing this in v4
Snipped
>
> On Wed, 30 Oct 2024 11:11:31 +0530
> Vipin Varghese wrote:
>
> > + if (topo_cnfg.io) {
> > + free(topo_cnfg.io);
> > + topo_cnfg.io = NULL;
> > + }
>
> No need to check for NULL before calling free.
Thank you Stepehen on this, the reason why we speci
Snipped
>
> On Wed, 30 Oct 2024 11:11:31 +0530
> Vipin Varghese wrote:
>
> > topo_cnfg.l3[j] = (struct core_domain_mapping *)
> > + malloc(sizeof(struct
> > core_domain_mapping));
>
> Minor nit, no need to cast return value from malloc
Snipped
> > ---
>
>
> Test fails on ARM platform:
>
>
> lcore 19, socket 0, role RTE, cpuset 19
> Control thread running successfully
> INFO: lcore count topology: none (12), io (1), l3 (1), l2 (1), l1 (1).
> INFO: worker lcore count topology: none (11), io (1), l3 (1), l2 (1), l1 (1).
> INFO:
Snipped
> > > >
> > > > I see compilation failure on ARM platforms due to missing header
> > > > include.
> > > >
> > > > ../examples/helloworld/main.c: In function 'parse_topology':
> > > > ../examples/helloworld/main.c:83:13: error: implicit declaration
> > > > of function 'strtoul'; did you me
> Hi Pavan,
>
> Snipped
>
> >
> > I see compilation failure on ARM platforms due to missing header include.
> >
> > ../examples/helloworld/main.c: In function 'parse_topology':
> > ../examples/helloworld/main.c:83:13: error: implicit declaration of
> > function 'strtoul'; did you mean 'strtok'?
Hi Pavan,
Snipped
>
> I see compilation failure on ARM platforms due to missing header include.
>
> ../examples/helloworld/main.c: In function 'parse_topology':
> ../examples/helloworld/main.c:83:13: error: implicit declaration of function
> 'strtoul';
> did you mean 'strtok'? [-Wimplicit-func
[AMD Official Use Only - AMD Internal Distribution Only]
> > >
> > > > 1. if there are specific SoC which do not populate the information
> > > > at all? If yes are they in DTS?
> > >
> > > This information is populated correctly for all SOCs, comment was on
> > > the script.
> >
> > Please note,
[AMD Official Use Only - AMD Internal Distribution Only]
>
> When are you going to send a new version?
We had been testing this on various Intel and AMD platforms. We have completed
testing over sub-NUMA domains on both SoC.
We will be sharing the new patch (rfc-v2) before 22 Oct 2024.
>
> Need:
[Public]
Snipped
> >
> >
> >Based on the discussions we agreed on sharing version-2 FRC for
> >extending API as `rte_get_next_lcore_extnd` with extra argument as
> >`flags`.
> >
> >As per my ideation, for the API ` rte_get_next_sibling_core`, the above
> >API can easily with f
[Public]
Snipped
>
>
> To to be clear; it's something like this I think of when I say "DOM-style"
> API.
>
> #ifndef RTE_HWTOPO_H
> #define RTE_HWTOPO_H
>
> struct rte_hwtopo_node;
>
> enum rte_hwtopo_node_type {
> RTE_HWTOPO_NODE_TYPE_CPU_CORE,
> RTE_HWTOPO_NODE_TYPE_CACHE,
> RT
[AMD Official Use Only - AMD Internal Distribution Only]
> Thank you Mattias for the information, as shared by in the reply
> with
> >> Anatoly we want expose a new API `rte_get_next_lcore_ex` which
> >> intakes a extra argument `u32 flags`.
> The flags can be RTE_GET_LCORE_L1 (S
[AMD Official Use Only - AMD Internal Distribution Only]
> >
> > For the naming, would "rte_get_next_sibling_core" (or lcore if you
> > prefer) be a clearer name than just adding "ex" on to the end of the
> > existing function?
> >
> > Looking logically, I'm not sure about the BOOST_ENABLED and
[Public]
> > What use case do you have in mind? What's on top of my list is a scenario
> where a DPDK app gets a bunch of cores (e.g., -l ) and tries to figure
> out how best make use of them. It's not going to "skip" (ignore, leave unused)
> SMT siblings, or skip non-boosted cores, it would ju
[Public]
> > > >
> > > >
> > > >>>
> > > >>>
> > > >>> Thank you Mattias for the comments and question, please let me
> > > >>> try to explain the same below
> > > >>>
> > > We shouldn't have a separate CPU/cache hierarchy API instead?
> > > >>>
> > > >>> Based on the intention to bring
[Public]
Snipped
>
>
>
> >>
> >>
> >> Thank you Mattias for the comments and question, please let me
> >> try to explain the same below
> >>
> >>> We shouldn't have a separate CPU/cache hierarchy API instead?
> >>
> >> Based on the intention to bri
[AMD Official Use Only - AMD Internal Distribution Only]
>
> On Wed, 11 Sep 2024 03:13:14 +0000
> "Varghese, Vipin" wrote:
>
> > > Agreed. This one of those cases where the existing project hwloc
> > > which is part of open-mpi is more complete and we
[AMD Official Use Only - AMD Internal Distribution Only]
>
> On 2024-09-09 16:22, Varghese, Vipin wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> >
> >
> >>>
> >>>
> >>> Thank you Mattias for the
[AMD Official Use Only - AMD Internal Distribution Only]
> > >
> > > Thank you Mattias for the comments and question, please let me try
> > > to explain the same below
> > >
> > >> We shouldn't have a separate CPU/cache hierarchy API instead?
> > >
> > > Based on the intention to bring in CPU l
[AMD Official Use Only - AMD Internal Distribution Only]
> >
> >
> > Thank you Mattias for the comments and question, please let me try to
> > explain the same below
> >
> >> We shouldn't have a separate CPU/cache hierarchy API instead?
> >
> > Based on the intention to bring in CPU lcores whic
[AMD Official Use Only - AMD Internal Distribution Only]
>
> >> Yes, this does help clarify things a lot as to why current NUMA
> >> support would be insufficient to express what you are describing.
> >>
> >> However, in that case I would echo sentiment others have expressed
> >> already as thi
[AMD Official Use Only - AMD Internal Distribution Only]
> > > >> --- a/app/test-pmd/macswap_sse.h
> > > >> +++ b/app/test-pmd/macswap_sse.h
> > > >> @@ -16,13 +16,13 @@ do_macswap(struct rte_mbuf *pkts[], uint16_t
> nb,
> > > >>uint64_t ol_flags;
> > > >>int i;
> > > >>
[AMD Official Use Only - AMD Internal Distribution Only]
> >Some SOCs may only show upper-level caches here, therefore
> > cannot be use blindly without knowing the SOC.
> >
> > Can you please help us understand
> >
>
> For instance, in Neoverse N1 can disable the use of SLC as LLC (a B
I recently looked into how Intel's Sub-NUMA Clustering would work
within
DPDK, and found that I actually didn't have to do anything, because the
SNC "clusters" present themselves as NUMA nodes, which DPDK already
supports natively.
yes, this is correct. In Intel Xeon Platinum BIOS one can e
-unsigned int rte_get_next_lcore(unsigned int i, int skip_main, int wrap)
+#define LCORE_GET_LLC \
+ "ls -d /sys/bus/cpu/devices/cpu%u/cache/index[0-9] | sort -r
| grep -m1 index[0-9] | awk -F '[x]' '{print $2}' "
This won't work for some SOCs.
Thank you for your response. ple
Thank you Antaloy for the response. Let me try to share my understanding.
I recently looked into how Intel's Sub-NUMA Clustering would work within
DPDK, and found that I actually didn't have to do anything, because the
SNC "clusters" present themselves as NUMA nodes, which DPDK already
support
Thank you Mattias for the comments and question, please let me try to
explain the same below
We shouldn't have a separate CPU/cache hierarchy API instead?
Based on the intention to bring in CPU lcores which share same L3 (for
better cache hits and less noisy neighbor) current API focuses
+ "ls -d /sys/bus/cpu/devices/cpu%u/cache/index[0-9] | sort -r | grep
-m1 index[0-9] | awk -F '[x]' '{print $2}' "
NAK
Running shell commands from EAL is non-portable and likely to be flagged by
security scanning tools.
Do it in C please.
Thank you Stephen, for pointing this ou
On 8/27/2024 11:09 PM, Stephen Hemminger wrote:
not sure why compiler would not decide to already use a register here?
Hi Stephen, I totally agree with your point, but in practice it did not
use registers for code generation.
On 8/21/2024 8:25 PM, Stephen Hemminger wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
On Wed, 21 Aug 2024 20:08:55 +0530
Vipin Varghese wrote:
diff --git a/app/test-pmd/macswap_sse.h b/app/test-p
Hi Bruce,
Thanks for highlighting the variance. We found this was an internal test
bed configuration issue. We are sharing the next version of the same
patch with updated numbers.
On 7/23/2024 10:42 PM, Bruce Richardson wrote:
Caution: This message originated from an External Source. Use pr
Thank you Konstantin for the reply, Adding back the comments as it is
not reflected the mail thread
diff --git a/app/test-dma-perf/benchmark.c b/app/test-dma-perf/benchmark.c
index 9b1f58c78c..b6d0dbe4c0 100644
--- a/app/test-dma-perf/benchmark.c
+++ b/app/test-dma-perf/benchmark.c
@@ -311,9
diff --git a/app/test-dma-perf/benchmark.c b/app/test-dma-perf/benchmark.c
index 9b1f58c78c..b6d0dbe4c0 100644
--- a/app/test-dma-perf/benchmark.c
+++ b/app/test-dma-perf/benchmark.c
@@ -311,9 +311,14 @@ setup_memory_env(struct test_configure *cfg, struct
rte_mbuf ***srcs,
uint32_t nr_bu
- printf("\nTotal Bandwidth: %.3lf Gbps, Total MOps: %.3lf\n",
bandwidth_total, mops_total);
+ printf("\nAverage Cycles/op per worker: %.1f, Total Bandwidth: %.3lf Gbps,
Total MOps: %.3lf\n",
+ (avg_cycles_total * (float) 1.0) / nb_workers,
bandwidth_total, mops_to
- printf("Error: Source or destination numa exceeds the acture numa
nodes.\n");
+ printf("Error: %s numa exceeds the available numa nodes.\n",
+ (cfg->src_numa_node >= nr_sockets) ? "Source" :
"Destination");
Thank you for comments, pleas
- The size of the memory footprint.
+ The size of the memory footprint in megabytes (MB) for source and
destination.
I prefer not add "for source and destination", it makes sense without this, and
maybe future test like fill don't have source buffer.
The current dma-perf application, mak
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
For configuration parameters `mem_size` and `buf_size` are represented
as megabytes and bytes respectively in application. Update the
documentation to represe
On 2/27/2024 5:57 PM, fengchengwen wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
Hi Vipin,
On 2024/2/27 17:57, Varghese, Vipin wrote:
On 2/26/2024 7:35 AM, fengchengwen wrote:
Caution: This
On 2/27/2024 6:39 PM, fengchengwen wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
Hi Vipin,
On 2024/2/27 17:50, Varghese, Vipin wrote:
On 2/23/2024 3:15 PM, fengchengwen wrote:
Caution: This
On 2/23/2024 3:15 PM, fengchengwen wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
Hi Vipin,
On 2023/12/20 0:40, Vipin Varghese wrote:
Modify the user display data with total average latency per wo
On 2/26/2024 7:35 AM, fengchengwen wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
Hi Vipin,
On 2023/12/20 19:03, Vipin Varghese wrote:
From: Vipin Varghese
Replace pktmbuf pool with mempool, thi
On 2/23/2024 3:15 PM, fengchengwen wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
Hi Vipin,
On 2023/12/20 0:40, Vipin Varghese wrote:
Modify the user display data with total average latency per wo
On 2/1/2024 4:02 PM, David Marchand wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
On Wed, Dec 6, 2023 at 12:31 PM Vipin Varghese wrote:
The default value for CFG_VALUE_LEN is set to 256 character
On 1/16/2024 8:44 PM, Thomas Monjalon wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
There was no comment on this doc.
It is RFC, is it ready to merge?
new patch shared doc/linux_gsg: add amd confi
On 12/20/2023 3:02 PM, David Marchand wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
On Wed, Dec 20, 2023 at 10:31 AM Varghese, Vipin wrote:
On 12/20/2023 2:57 PM, David Marchand wrote:
Caution
On 12/20/2023 2:57 PM, David Marchand wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
On Wed, Dec 20, 2023 at 10:25 AM Varghese, Vipin wrote:
Got `Superseded` is there a new version shared for
Got `Superseded` is there a new version shared for `AMD tuning guide`?
On 10/10/2023 9:04 PM, Vipin Varghese wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
Add AMD EPYC SoC tuning guide as new setcio
just received an update marking this as `Superseded`. I will send again
with `ACK` also
Thank you Morten for the understanding
*From:* Morten Brørup
*Sent:* 12 December 2023 23:39
*To:* Varghese, Vipin ; Bruce
[AMD Official Use Only - General]
Thank you Morten for the understanding
From: Morten Brørup
Sent: 12 December 2023 23:39
To: Varghese, Vipin ; Bruce Richardson
Cc: Yigit, Ferruh ; dev@dpdk.org ;
sta...@dpdk.org ; honest.ji...@foxmail.com
; P, Thiyagarajan
[Public]
Sharing a few critical points based on my exposure to the dma-perf application
below
On Tue, Dec 12, 2023 at 04:16:20PM +0100, Morten Brørup wrote:
> +TO: Bruce, please stop me if I'm completely off track here.
>
> > From: Ferruh Yigit [mailto:ferruh.yi...@amd.com] Sent: Tuesday, 12
>
[AMD Official Use Only - General]
From: Bruce Richardson
Sent: 06 December 2023 21:20
To: Varghese, Vipin
Cc: Dumitrescu, Cristian ; dev@dpdk.org
; Yigit, Ferruh ; Parikh, Neerav
Subject: Re: [PATCH] cfgfile: increase value length
Caution: This message originated from an External Source
ge,
https://patchwork.dpdk.org/project/dpdk/patch/20231206112952.1588-1-vipin.vargh...@amd.com/
I will re work and share v2.
From: Dumitrescu, Cristian
Sent: 06 December 2023 19:04
To: Richardson, Bruce ; Varghese, Vipin
Cc: dev@dpdk.org ; Yigit, Ferruh
Subject: RE: [PATC
iew there as `setting const * for always_inline
definition has the same effect too`.
> -Original Message-
> From: Jiang, Cheng1
> Sent: Thursday, September 21, 2023 7:58 AM
> To: Varghese, Vipin ; tho...@monjalon.net;
> dev@dpdk.org; ano...@marvell.com
> Cc: Yigit, Ferruh ;
[AMD Official Use Only - General]
> -Original Message-
> From: Anoob Joseph
> Sent: Wednesday, August 16, 2023 12:57 PM
> To: Varghese, Vipin
> Cc: Yigit, Ferruh ; cheng1.ji...@intel.com;
> sta...@dpdk.org; tho...@monjalon.net; dev@dpdk.org; Jerin Jacob
> Kollanu
[AMD Official Use Only - General]
Hi Anoob,
> -Original Message-
> From: Anoob Joseph
> Sent: Wednesday, August 16, 2023 11:38 AM
> To: Varghese, Vipin
> Cc: Yigit, Ferruh ; cheng1.ji...@intel.com;
> sta...@dpdk.org; tho...@monjalon.net; dev@dpdk.org; Jerin Jac
[AMD Official Use Only - General]
Apologies, marking this as `NA`. After recheck of this logic without use of `
rte_mbuf_data_iova` will result in mbuf meta-data corruption.
Need to fix this in a different way.
> -Original Message-
> From: Vipin Varghese
> Sent: Tuesday, August 15, 202
[AMD Official Use Only - General]
> -Original Message-
> From: Stephen Hemminger
> Sent: Sunday, August 13, 2023 9:22 PM
> To: Varghese, Vipin
> Cc: tho...@monjalon.net; dev@dpdk.org; Yigit, Ferruh
>
> Subject: Re: [PATCH] usertools: suggest use of hwloc for new
[AMD Official Use Only - General]
> -Original Message-
> From: Stephen Hemminger
> Sent: Saturday, August 12, 2023 8:30 PM
> To: Varghese, Vipin
> Cc: tho...@monjalon.net; dev@dpdk.org; Yigit, Ferruh
>
> Subject: Re: [PATCH] usertools: suggest use of hwloc for new
[AMD Official Use Only - General]
> > > >
> > > > From last email from my end `we should promote and document the
> > > changes provided the existing tool is phased out and use lstopo`.
> > > >
> > > > Note:
> > > > 1. This is with assumption that both Linux and Windows `lstopo` is
> > > > modif
[AMD Official Use Only - General]
> -Original Message-
> From: Bruce Richardson
> Sent: Tuesday, July 25, 2023 9:49 PM
> To: dev@dpdk.org
> Cc: Varghese, Vipin
> Subject: Re: [PATCH] doc/dmadevs: add note clarifying naming of idxd devices
>
> Caution: This me
[AMD Official Use Only - General]
> -Original Message-
> From: Thomas Monjalon
> Sent: Monday, July 17, 2023 8:37 PM
> To: Stephen Hemminger ; Varghese, Vipin
>
> Cc: david.march...@redhat.com; Tummala, Sivaprasad
> ; dev@dpdk.org
> Subject: Re: [PATCH] use
[AMD Official Use Only - General]
> -Original Message-
> From: Thomas Monjalon
> Sent: Tuesday, July 11, 2023 9:56 PM
> To: Varghese, Vipin ; Stephen Hemminger
>
> Cc: david.march...@redhat.com; Tummala, Sivaprasad
> ; dev@dpdk.org
> Subject: Re: [PATCH] use
d in forums, stackoverflow and github on NUMA to
CPU pinning, hence enhanced the tool to accommodate the changes.
> -Original Message-
> From: Thomas Monjalon
> Sent: Wednesday, June 14, 2023 8:00 PM
> To: Yigit, Ferruh
> Cc: Varghese, Vipin ; Dmitry Kozlyuk
> ; dav
[Public]
Hi Michael,
Thank you for looking into the change, please find my comments shared below
> >
> > Add code to read the virtual address width for AMD processors.
> >
> > Signed-off-by: Michael Piszczek
> > ---
> > drivers/bus/pci/linux/pci.c | 43
> > +++
grams\\Python\\Python310\\DLLs',
'C:\\Users\\Administrator\\AppData\\Local\\Programs\\Python\\Python310\\lib',
'C:\\Users\\Administrator\\AppData\\Local\\Programs\\Python\\Python310',
'C:\\Users\\Administrator\\AppData\\Local\\Programs\\Python\\Python310\\lib\\site-p
[AMD Official Use Only]
> -Original Message-
> From: Dmitry Kozlyuk
> Sent: Tuesday, March 29, 2022 4:21 AM
> To: Varghese, Vipin
> Cc: Thomas Monjalon ;
> david.march...@redhat.com; Tummala, Sivaprasad
> ; dev@dpdk.org
> Subject: Re: [PATCH] meson: upda
1 - 100 of 352 matches
Mail list logo
