RE: [PATCH v2] app/dma-perf: fix physical address seg-fault

2023-10-04 Thread Varghese, Vipin
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 ;

Re: [PATCH] app/testpmd: improve sse based macswap

2024-07-25 Thread Varghese, Vipin
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

Re: [PATCH v2 1/3] app/testpmd: add register keyword

2024-08-27 Thread Varghese, Vipin
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

Re: [PATCH v2 1/3] app/testpmd: add register keyword

2024-08-29 Thread Varghese, Vipin
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.

Re: [RFC 1/2] eal: add llc aware functions

2024-09-01 Thread Varghese, Vipin
+ "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

Re: [RFC 1/2] eal: add llc aware functions

2024-09-01 Thread Varghese, Vipin
-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

Re: [RFC 0/2] introduce LLC aware functions

2024-09-01 Thread Varghese, Vipin
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

Re: [RFC 0/2] introduce LLC aware functions

2024-09-01 Thread Varghese, Vipin
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

Re: [RFC 0/2] introduce LLC aware functions

2024-09-02 Thread Varghese, Vipin
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

RE: [PATCH v2 0/3] doc: build on Windows

2022-05-11 Thread Varghese, Vipin
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

Re: [dpdk-dev] [PATCH] bus/pci: fix numa node return value

2021-09-24 Thread Varghese, Vipin
Hi Pallavi, Assuming the intention is set SOCKET_ID_ANY for faulty cases, couple of observation. In Linux ``` if (access(filename, F_OK) != -1) { if (eal_parse_sysfs_value(filename, &tmp) == 0) dev->device.numa_node = tmp; else

Re: [PATCH] app/dma-perf: add average latency per worker

2024-02-27 Thread Varghese, Vipin
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

Re: [PATCH v2] app/dma-perf: replace pktmbuf with mempool objects

2024-02-27 Thread Varghese, Vipin
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

Re: [PATCH] app/dma-perf: add average latency per worker

2024-02-27 Thread Varghese, Vipin
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

Re: [PATCH] app/dma-perf: add average latency per worker

2024-02-27 Thread Varghese, Vipin
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

Re: [PATCH v2] app/dma-perf: replace pktmbuf with mempool objects

2024-02-27 Thread Varghese, Vipin
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

Re: [PATCH] app/dma-perf: replace pktmbuf with mempool objects

2023-12-12 Thread Varghese, Vipin
[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 >

Re: [PATCH] app/dma-perf: replace pktmbuf with mempool objects

2023-12-12 Thread Varghese, Vipin
[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

Re: [PATCH] app/dma-perf: replace pktmbuf with mempool objects

2023-12-20 Thread Varghese, Vipin
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

Re: [RFC] doc/linux_gsg: add amd configuration section

2023-12-20 Thread Varghese, Vipin
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

Re: [RFC] doc/linux_gsg: add amd configuration section

2023-12-20 Thread Varghese, Vipin
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

Re: [RFC] doc/linux_gsg: add amd configuration section

2023-12-20 Thread Varghese, Vipin
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

Re: [RFC] doc/linux_gsg: add amd configuration section

2024-01-24 Thread Varghese, Vipin
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

Re: [PATCH] cfgfile: increase value length

2024-02-01 Thread Varghese, Vipin
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

RE: [PATCH] usertools: enhance logic to display NUMA

2023-07-18 Thread Varghese, Vipin
[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

RE: [PATCH] doc/dmadevs: add note clarifying naming of idxd devices

2023-07-25 Thread Varghese, Vipin
[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

RE: [PATCH] usertools: enhance logic to display NUMA

2023-08-12 Thread Varghese, Vipin
[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

RE: [PATCH] usertools: suggest use of hwloc for new cpu

2023-08-12 Thread Varghese, Vipin
[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

RE: [PATCH] usertools: suggest use of hwloc for new cpu

2023-08-13 Thread Varghese, Vipin
[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

RE: [PATCH] app/dma-perf: fix physical address seg-fault

2023-08-15 Thread Varghese, Vipin
[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

RE: [PATCH] app/dma-perf: fix physical address seg-fault

2023-08-16 Thread Varghese, Vipin
[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

RE: [EXT] [PATCH] app/dma-perf: fix physical address seg-fault

2023-08-16 Thread Varghese, Vipin
[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

Re: [PATCH] cfgfile: increase value length

2023-12-06 Thread Varghese, Vipin
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

Re: [PATCH] cfgfile: increase value length

2023-12-06 Thread Varghese, Vipin
[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

Re: [PATCH] doc: update size parameter details

2024-03-05 Thread Varghese, Vipin
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

Re: [PATCH] doc: update size parameter details

2024-03-07 Thread Varghese, Vipin
- 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

Re: [PATCH] app/dma-perf: calrify incorrect NUMA config

2024-03-07 Thread Varghese, Vipin
- 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

Re: [PATCH v2] app/dma-perf: add average latency per worker

2024-03-07 Thread Varghese, Vipin
- 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

Re: [PATCH v2] app/dma-perf: calrify incorrect NUMA config

2024-03-11 Thread Varghese, Vipin
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

Re: [PATCH v2] app/dma-perf: calrify incorrect NUMA config

2024-03-19 Thread Varghese, Vipin
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

RE: [PATCH] usertools: enhance logic to display NUMA

2023-07-10 Thread Varghese, Vipin
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

RE: [PATCH] usertools: enhance logic to display NUMA

2023-07-14 Thread Varghese, Vipin
[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

RE: [PATCH v2] pci: read amd iommu virtual address width

2022-10-10 Thread Varghese, Vipin
[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 > > +++

RE: [PATCH] usertools: enhance logic to display NUMA

2022-03-27 Thread Varghese, Vipin
[AMD Official Use Only] Hi Thomas, 26/03/2022 08:32, Vipin Varghese: > enhance python logic to accomadate NUMA information. Current logic > considers physical socket with CPU threads to core map. With new AMD > SKU vairant NUMA is no longer same as SOCKET. Single physical socket > can be pa

RE: [PATCH] meson: update doc logic for Windows

2022-03-27 Thread Varghese, Vipin
[AMD Official Use Only] Hi Thomas, Thank you for looking at this problem. 26/03/2022 03:59, Vipin Varghese: > Support for shell scripts doxy-html-custom, generate_doxygen and > generate_examples are absent. The current patch address the same by > disabling document build notifying the user.

RE: [PATCH] meson: update doc logic for Windows

2022-03-28 Thread Varghese, Vipin
[AMD Official Use Only] Hi Dmitry, Thanks for inputs, please find my question below 2022-03-28 03:02 (UTC+), Varghese, Vipin: > [AMD Official Use Only] > > Hi Thomas, > > > > Thank you for looking at this problem. > > 26/03/2022 03:59, Vipin Varghese: > &g

RE: [PATCH] meson: update doc logic for Windows

2022-03-28 Thread Varghese, Vipin
[AMD Official Use Only] > > 26/03/2022 03:59, Vipin Varghese: > > Support for shell scripts doxy-html-custom, generate_doxygen and > > generate_examples are absent. The current patch address the same by > > disabling document build notifying the user. > > It should not prevent generating guides

RE: [PATCH] dma/skeleton: support multiple instances

2022-03-28 Thread Varghese, Vipin
[AMD Official Use Only] Verified on ` AMD EPYC 7713 64-Core Processor` platform with argument ` --vdev=dma_skeleton0,lcore=4 --vdev=dma_skeleton1,lcore=5`. Tested-by: Vipin Varghese -Original Message- From: Sivaprasad Tummala Sent: Monday, March 28, 2022 7:53 PM To: fengcheng...@hua

RE: [PATCH] meson: update doc logic for Windows

2022-03-28 Thread Varghese, Vipin
[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

Re: [dpdk-dev] [dpdk-users] DPDK issue with Marvell NIC QLogic Corp. FastLinQ QL41000

2021-05-26 Thread Varghese, Vipin
Based on the logs shared from `Turing Team`, the observation is as follows 1. 1GB huge pages are used in the application ```logs 12:46:11.792 §EAL: No free hugepages reported in hugepages-2048kB 12:46:11.792 §EAL: No available hugepages reported in hugepages-2048kB ``` 2. Issue comes right at `d

RE: [RFC 1/2] eal: add llc aware functions

2024-09-06 Thread Varghese, Vipin
[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

RE: [PATCH v2 1/3] app/testpmd: add register keyword

2024-09-06 Thread Varghese, Vipin
[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; > > > >>

RE: [RFC 0/2] introduce LLC aware functions

2024-09-09 Thread Varghese, Vipin
[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

RE: [RFC 0/2] introduce LLC aware functions

2024-09-09 Thread Varghese, Vipin
[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

RE: [RFC 0/2] introduce LLC aware functions

2024-09-10 Thread Varghese, Vipin
[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

RE: [RFC 0/2] introduce LLC aware functions

2024-09-10 Thread Varghese, Vipin
[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

RE: [RFC 0/2] introduce LLC aware functions

2024-09-11 Thread Varghese, Vipin
[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

RE: [RFC 0/2] introduce LLC aware functions

2024-09-11 Thread Varghese, Vipin
[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

RE: [RFC 0/2] introduce LLC aware functions

2024-09-11 Thread Varghese, Vipin
[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

RE: [RFC 0/2] introduce LLC aware functions

2024-09-11 Thread Varghese, Vipin
[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

RE: [RFC 0/2] introduce LLC aware functions

2024-09-11 Thread Varghese, Vipin
[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

RE: [RFC 0/2] introduce LLC aware functions

2024-09-12 Thread Varghese, Vipin
[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

RE: [RFC 0/2] introduce LLC aware functions

2024-09-12 Thread Varghese, Vipin
[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

RE: [RFC 0/2] introduce LLC aware functions

2024-09-12 Thread Varghese, Vipin
[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

Re: [dpdk-dev] [PATCH v2 19/20] doc: add ICE description and update release note

2018-12-03 Thread Varghese, Vipin
Hi, Thanks for adding details for secondary multi process in limitations section, even though the API were expected. > -Original Message- > From: dev On Behalf Of Wenzhuo Lu > Sent: Monday, December 3, 2018 12:37 PM > To: dev@dpdk.org > Cc: Lu, Wenzhuo > Subject: [dpdk-dev] [PATCH v2

Re: [dpdk-dev] [PATCH v2 02/20] net/ice: support device initialization

2018-12-03 Thread Varghese, Vipin
Hi, snipped > +# Compile burst-oriented ICE PMD driver # CONFIG_RTE_LIBRTE_ICE_PMD=y Based on ' https://patches.dpdk.org/patch/48488/' it is suggested to configure. But here is it already set to 'y'. Is this correct? If yes can you update ' https://patches.dpdk.org/patch/48488/' snipped

Re: [dpdk-dev] [PATCH v2 20/20] net/ice: support meson build

2018-12-03 Thread Varghese, Vipin
Should not meson build option be add start. That is in patch 1/20 so compile options does not fail? Thanks Vipin Varghese

Re: [dpdk-dev] [PATCH v2 01/20] net/ice: add base code

2018-12-03 Thread Varghese, Vipin
Snipped > +Intel® ICE driver > +== > + > +This directory contains source code of FreeBSD ice driver of version > +2018.10.30 released by the team which develops > +basic drivers for any ice NIC. The directory of base/ contains the > +original source package. > +This driver is valid

Re: [dpdk-dev] [PATCH v2 02/20] net/ice: support device initialization

2018-12-03 Thread Varghese, Vipin
Snipped > + /* Set the info.ingress_table and info.egress_table > + * for UP translate table. Now just set it to 1:1 map by default > + * -- 0b 111 110 101 100 011 010 001 000 == 0xFAC688 > + */ > + info->ingress_table = rte_cpu_to_le_32(0x00FAC688); > + info->egress_

Re: [dpdk-dev] [PATCH v2 03/20] net/ice: support device and queue ops

2018-12-03 Thread Varghese, Vipin
snipped > + > +static int ice_init_rss(struct ice_pf *pf) { > + struct ice_hw *hw = ICE_PF_TO_HW(pf); > + struct ice_vsi *vsi = pf->main_vsi; > + struct rte_eth_dev *dev = pf->adapter->eth_dev; > + struct rte_eth_rss_conf *rss_conf; > + struct ice_aqc_get_set_rss_keys key; > +

Re: [dpdk-dev] [PATCH v2 04/20] net/ice: support getting device information

2018-12-03 Thread Varghese, Vipin
snipped > +static void > +ice_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info > +*dev_info) { > + struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private); > + struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data- > >dev_private); > + struct ice_vsi *vsi = pf->main

Re: [dpdk-dev] [PATCH v2 05/20] net/ice: support packet type getting

2018-12-03 Thread Varghese, Vipin
snipped > +static inline uint32_t > +ice_get_default_pkt_type(uint16_t ptype) { Suggestion: should we check 'ptype >= RTE_PTYPE_UNKNOWN ' return? > + static const uint32_t type_table[ICE_MAX_PKT_TYPE] > + __rte_cache_aligned = { > + /* L2 types */ > + /* [0

Re: [dpdk-dev] [PATCH v2 07/20] net/ice: support MTU setting

2018-12-03 Thread Varghese, Vipin
snipped > +static int > +ice_mtu_set(struct rte_eth_dev *dev, uint16_t mtu) { > + struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private); > + struct rte_eth_dev_data *dev_data = pf->dev_data; > + uint32_t frame_size = mtu + ETHER_HDR_LEN > + + ETHER_

Re: [dpdk-dev] [PATCH v2 14/20] net/ice: support statistics

2018-12-03 Thread Varghese, Vipin
snipped > + ns->eth.tx_bytes -= (ns->eth.tx_unicast + ns->eth.tx_multicast + > + ns->eth.tx_broadcast) * ETHER_CRC_LEN; In earlier patch for 'mtu set check' we added VSI SWITCH VLAN. Should we add VSI VLAN here? snipped

Re: [dpdk-dev] [PATCH v2 16/20] net/ice: support basic RX/TX

2018-12-03 Thread Varghese, Vipin
snipped > +uint16_t > +ice_recv_pkts(void *rx_queue, > + struct rte_mbuf **rx_pkts, > + uint16_t nb_pkts) > +{ > + struct ice_rx_queue *rxq = rx_queue; > + volatile union ice_rx_desc *rx_ring = rxq->rx_ring; > + volatile union ice_rx_desc *rxdp; > + union ice_rx_

Re: [dpdk-dev] [PATCH v2 16/20] net/ice: support basic RX/TX

2018-12-03 Thread Varghese, Vipin
May this logic is just to allocate the initial descriptor and not actual, if yes please ignore my comments. > -Original Message- > From: dev On Behalf Of Varghese, Vipin > Sent: Tuesday, December 4, 2018 11:12 AM > To: Lu, Wenzhuo ; dev@dpdk.org > Cc: Lu, Wenzhuo ; Yang

Re: [dpdk-dev] [PATCH v2 07/20] net/ice: support MTU setting

2018-12-03 Thread Varghese, Vipin
Can you point me to the patch where 'get_mtu' is defined? > -Original Message- > From: dev On Behalf Of Varghese, Vipin > Sent: Tuesday, December 4, 2018 10:56 AM > To: Lu, Wenzhuo ; dev@dpdk.org > Cc: Lu, Wenzhuo ; Yang, Qiming > ; Li, Xiaoyun ; Wu, Jingjing

Re: [dpdk-dev] [PATCH] lib: add warning for NULL pointer

2018-12-04 Thread Varghese, Vipin
Hi, Should not the warning be stated for ' alloc_completion' failure Snipped > flows->num_packets * flows->categories); > } > > + if (flows->last_cmplt == NULL) > + RTE_LOG(WARNING, MALLOC, "packet tries allocate > fail

Re: [dpdk-dev] [PATCH] lib: add warning for NULL pointer

2018-12-04 Thread Varghese, Vipin
Do you plan to check for all iteration for ' flows->last_cmplt ' is successful? > -Original Message- > From: dev On Behalf Of Varghese, Vipin > Sent: Wednesday, December 5, 2018 10:07 AM > To: Yang, Qiming ; dev@dpdk.org > Cc: Yang, Qiming ; sta...@dpdk.

Re: [dpdk-dev] About the data payload of rte_mbuf?

2018-12-05 Thread Varghese, Vipin
Hi, A quick query from your email Snipped > ipv4_hdr = rte_pktmbuf_mtod_offset(m, struct ipv4_hdr *, sizeof(struct > ether_hdr)); Questions: 1. Should not be sizeof(struct ipv4_hdr) since you are passing second argument as ipv4_hdr? 2. you are getting packets which starts from ether or ipv4?

Re: [dpdk-dev] [PATCH v2 01/20] net/ice: add base code

2018-12-05 Thread Varghese, Vipin
Hi Wenzhuo, thanks for the updates, couple of follow up and suggestions snipped > > > > > +Intel® ICE driver > > > +== > > > + > > > +This directory contains source code of FreeBSD ice driver of > > > +version > > > +2018.10.30 released by the team which develops basic drivers for

Re: [dpdk-dev] [PATCH v2 20/20] net/ice: support meson build

2018-12-05 Thread Varghese, Vipin
Hi Wenzhuo snipped > > > > Should not meson build option be add start. That is in patch 1/20 so > > compile options does not fail? > It will not fail. Enabling the compile earlier only means the code can be > compiled. > But, to use this device we do need the whole patch set. From this point of

Re: [dpdk-dev] [PATCH v2 19/20] doc: add ICE description and update release note

2018-12-05 Thread Varghese, Vipin
Thanks Wenzhuo snipped > > > > Do we support Traffic Manager and Inline Crypto? If not, can we add > > this also to limitations? > The style is only listed supported features here. I don't think we'll list > everything > not supported as limitation. Thanks for the correction in format, hence the

Re: [dpdk-dev] [PATCH v2 03/20] net/ice: support device and queue ops

2018-12-05 Thread Varghese, Vipin
Hi Wenzhuo, Please find my updates below snipped > > > + if (!vsi->rss_key) > > > + vsi->rss_key = rte_zmalloc("rss_key", > > > +vsi->rss_key_size, 0); > > > + if (!vsi->rss_lut) > > > + vsi->rss_lut = rte_zmalloc("rss_lut", > > > +

Re: [dpdk-dev] [PATCH v2 02/20] net/ice: support device initialization

2018-12-05 Thread Varghese, Vipin
snipped > > > + ice_init_controlq_parameter(hw); > > > + > > > + ret = ice_init_hw(hw); > > > + if (ret) { > > > + PMD_INIT_LOG(ERR, "Failed to initialize HW"); > > > + return -EINVAL; > > > + } > > > > Definition for ice_init_hw in patch 01/20 does not check for primary- > > second

Re: [dpdk-dev] About the data payload of rte_mbuf?

2018-12-05 Thread Varghese, Vipin
en, that if can promise its type is IPv4? Capture the packet, I am sure it will have ethernet header + ipv4 header + payload and not ipv4 header + payload. -- Original -- From: "Varghese, Vipin"mailto:vipin.vargh...@intel.com>>; Date: Thu, Dec 6,

Re: [dpdk-dev] [PATCH v2 04/20] net/ice: support getting device information

2018-12-05 Thread Varghese, Vipin
> > > > snipped > > > +static void > > > +ice_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info > > > +*dev_info) { > > > + struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data- > > >dev_private); > > > + struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data- > > > >dev_private); > > > + s

Re: [dpdk-dev] [PATCH v2 14/20] net/ice: support statistics

2018-12-05 Thread Varghese, Vipin
Snipped > > > > snipped > > > + ns->eth.tx_bytes -= (ns->eth.tx_unicast + ns->eth.tx_multicast + > > > + ns->eth.tx_broadcast) * ETHER_CRC_LEN; > > > > In earlier patch for 'mtu set check' we added VSI SWITCH VLAN. Should > > we add VSI VLAN here? > Don't need. They're differen

Re: [dpdk-dev] [PATCH v2 16/20] net/ice: support basic RX/TX

2018-12-05 Thread Varghese, Vipin
> > > > snipped > > > +uint16_t > > > +ice_recv_pkts(void *rx_queue, > > > + struct rte_mbuf **rx_pkts, > > > + uint16_t nb_pkts) > > > +{ > > > + struct ice_rx_queue *rxq = rx_queue; > > > + volatile union ice_rx_desc *rx_ring = rxq->rx_ring; > > > + volatile union ice_rx_desc *rxdp; >

Re: [dpdk-dev] [PATCH v2 07/20] net/ice: support MTU setting

2018-12-05 Thread Varghese, Vipin
Thanks, I get what you are saying since by default ' rte_eth_dev_get_mtu' fetches MTU ' dev->data->mtu'. But is not ICE_DSI a switch so MTU would be picked up from switch HW ? > -Original Message- > From: Lu, Wenzhuo > Sent: Thursday, December 6,

Re: [dpdk-dev] [PATCH v2 01/20] net/ice: add base code

2018-12-05 Thread Varghese, Vipin
snipped > > > > > > > > > +Intel® ICE driver > > > > > +== > > > > > + > > > > > +This directory contains source code of FreeBSD ice driver of > > > > > +version > > > > > +2018.10.30 released by the team which develops basic drivers > > > > > +for any ice NIC. The directory of base

Re: [dpdk-dev] [PATCH v2 20/20] net/ice: support meson build

2018-12-05 Thread Varghese, Vipin
> -Original Message- > From: Lu, Wenzhuo > Sent: Thursday, December 6, 2018 11:29 AM > To: Varghese, Vipin ; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v2 20/20] net/ice: support meson build > > Hi Vipin, > > > > -Original Message- &

Re: [dpdk-dev] [PATCH v2 19/20] doc: add ICE description and update release note

2018-12-05 Thread Varghese, Vipin
> -Original Message- > From: Lu, Wenzhuo > Sent: Thursday, December 6, 2018 11:36 AM > To: Varghese, Vipin ; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v2 19/20] doc: add ICE description and update > release note > > Hi Vipin, > > > > -Orig

Re: [dpdk-dev] [PATCH v2 19/20] doc: add ICE description and update release note

2018-12-05 Thread Varghese, Vipin
snipped > > > > Thanks Wenzhuo > > > > > > > > snipped > > > > > > > > > > > > Do we support Traffic Manager and Inline Crypto? If not, can > > > > > > we add this also to limitations? > > > > > The style is only listed supported features here. I don't think > > > > > we'll list everything not supp

Re: [dpdk-dev] [PATCH v2 02/20] net/ice: support device initialization

2018-12-05 Thread Varghese, Vipin
snipped > > > > > + ice_init_controlq_parameter(hw); > > > > > + > > > > > + ret = ice_init_hw(hw); > > > > > + if (ret) { > > > > > + PMD_INIT_LOG(ERR, "Failed to initialize HW"); > > > > > + return -EINVAL; > > > > > + } > > > > > > > > Definition for ice_i

Re: [dpdk-dev] [PATCH v2 01/20] net/ice: add base code

2018-12-05 Thread Varghese, Vipin
snipped > > > > > > > > > > > > I this README persistent in upcoming releases of 'driver/net/ice'? > > > > > Yes. > > > > If Linux driver is enabled in 4.20.1 or higher, then will the > > > > wording 'This directory contains source code of FreeBSD ice driver > > > > of' still > > hold true? > > > A

Re: [dpdk-dev] [PATCH v2 03/20] net/ice: support device and queue ops

2018-12-06 Thread Varghese, Vipin
snipped > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Varghese, Vipin > > Sent: Thursday, December 6, 2018 5:27 AM > > To: Lu, Wenzhuo ; dev@dpdk.org > > Cc: Yang, Qiming ; Li, Xiaoyun > > ; Wu, Jingjing > > Su

Re: [dpdk-dev] [PATCH 4/4] doc: update release notes for enic

2018-12-10 Thread Varghese, Vipin
Hi Hyong, Thanks for sharing the information a query 'is ENIC Poll Mode Driver is been updated too?'(Section 16 under Network Interface Controller). a. If yes is it ok to link the patchwork in comment section? b. If no, will you be updating the documentation? Thanks Vipin Varghese > -Orig

Re: [dpdk-dev] [PATCH 4/4] doc: update release notes for enic

2018-12-11 Thread Varghese, Vipin
Hi Hyong, snipped > > Hi Hyong, > > > > Thanks for sharing the information a query 'is ENIC Poll Mode Driver is been > updated too?'(Section 16 under Network Interface Controller). > > a. If yes is it ok to link the patchwork in comment section? > > b. If no, will you be updating the documentation

Re: [dpdk-dev] [PATCH 4/4] doc: update release notes for enic

2018-12-11 Thread Varghese, Vipin
snipped > > Hi Hyong, > > > > snipped > > > > Hi Hyong, > > > > > > > > Thanks for sharing the information a query 'is ENIC Poll Mode > > > > Driver is been > > > updated too?'(Section 16 under Network Interface Controller). > > > > a. If yes is it ok to link the patchwork in comment section? > > >

  1   2   3   4   >