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 ;
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
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
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.
+ "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
-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 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
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
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
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
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
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/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/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
[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]
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
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
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
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
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 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 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
[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: 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]
> > > >
> > > > 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: 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]
> -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]
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]
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]
> -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
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
[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
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
- 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
- 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
- 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
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
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
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
[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
[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
> > +++
[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
[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.
[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
[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
[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
[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
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
[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
[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]
>
> >> 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]
> >
> >
> > 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]
> > >
> > > 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]
>
> 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]
>
> 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
[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
[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]
> > 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
[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
[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
[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
[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
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
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
Should not meson build option be add start. That is in patch 1/20 so compile
options does not fail?
Thanks
Vipin Varghese
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
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_
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;
> +
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
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
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_
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
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_
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
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
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
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.
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?
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
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
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
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",
> > > +
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
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,
> >
> > 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
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
> >
> > 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;
>
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,
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
> -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-
&
> -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
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
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
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
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
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
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
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 - 100 of 359 matches
Mail list logo
