Hi Morten,
What is the difference compare to rte_net_get_ptype(), which also parses
packet types and reports on header length.
In my application I have also done something similar about malformed
packets. IMO it's very useful to have return value indicate different types
of malformed packets, not
Also for the bulk API, another option would be passing in a `uint64_t
malformed_mask` and let the bulk function set the correspond bit (1 << pos) of
that mask if the packet at position pos is malformed.
void rte_hdr_parse_bulk(struct rte_mbuf **pkts, uint64_t *malformed_mask,
uint_fast16_t nb_p
Currently, lib latencystats works as follow:
* For every sample period, one packet is selected by RX callback to be later
used for latency measurement. That packet is marked with a timestamp.
* In TX callback, mbufs with non-zero timestamp are used for calculation.
I see a problem
The timestamp of a mbuf should be cleared after that mbuf was used for
latency calculation, otherwise future packets which reuse the same mbuf
would inherit that previous timestamp. The latencystats library looks
for mbuf with non-zero timestamp, thus incorrectly inherited value would
result in inc
The timestamp of a mbuf should be cleared after that mbuf was used for
latency calculation, otherwise future packets which reuse the same mbuf
would inherit that previous timestamp. The latencystats library looks
for mbuf with non-zero timestamp, thus incorrectly inherited value would
result in inc
The timestamp of a mbuf should be cleared after that mbuf was used for
latency calculation, otherwise future packets which reuse the same mbuf
would inherit that previous timestamp. The latencystats library looks
for mbuf with non-zero timestamp, thus incorrectly inherited value would
result in inc
Hi,
Thanks, I have sent a v2.
Any comment on the problem of dropped mbuf that I described in the cover
letter? In our application the max_latency_ns metric is useless since
after running for a while it would always take on obviously incorrect value
(up to a few minutes). I suspect the impact o
Hi Reshma,
> -Original Message-
> From: reshma.pat...@intel.com [mailto:reshma.pat...@intel.com]
> Sent: Thursday, September 20, 2018 8:09 PM
> To: long...@viettel.com.vn
> Cc: dev@dpdk.org
> Subject: RE: Incorrect latencystats implementation
>
>
>
> > -Original Message-
> > Fro
Hi Reshma,
> -Original Message-
> From: reshma.pat...@intel.com [mailto:reshma.pat...@intel.com]
> Sent: Friday, September 21, 2018 11:02 PM
> To: long...@viettel.com.vn; konstantin.anan...@intel.com; dev@dpdk.org
> Cc: Reshma Pattan
> Subject: [PATCH] latencystats: fix timestamp marking
> -Original Message-
> From: reshma.pat...@intel.com [mailto:reshma.pat...@intel.com]
> Sent: Friday, September 21, 2018 11:02 PM
> To: long...@viettel.com.vn; konstantin.anan...@intel.com; dev@dpdk.org
> Cc: Reshma Pattan
> Subject: [PATCH] latencystats: fix timestamp marking and latency
Hi Reshma,
I mean in the latencystats document. A few lines about what is taken away
by the library (the mbuf timestamp when PKT_RX_TIMESTAMP is set) would be
very helpful.
Best regards,
BL
- Original Message -
From: "reshma pattan"
To: long...@viettel.com.vn
Cc: "Konstantin Ananyev" ,
Hi everyone,
Suppose QEMU and DPDK support is not a requirement, is there any alternative
that could theoretically outperform virtio/vhost-user?
I'm asking this weird question because the existing virtio/vhost-user
interface, while regarded as the de facto path to VM, is currently one of
the maj
The timer_period option specified by users via config file
should have unit of 1 millisecond. However timer_period is
internally converted to unit of 10 millisecond.
Fixes: 4e14069328fc ("examples/ip_pipeline: measure CPU utilization")
Signed-off-by: Bao-Long Tran
---
examples/ip_pipeline/init.
Update f_post_init for pipeline frontend.
Move f_track from pipeline backend to pipeline frontend.
Signed-off-by: longtb5
---
doc/guides/sample_app_ug/ip_pipeline.rst | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/doc/guides/sample_app_ug/ip_pipeline.rst
b/doc/guides
From: longtb5
Update f_post_init for pipeline frontend.
Move f_track from pipeline backend to pipeline frontend.
Signed-off-by: Bao-Long Tran
Acked-by: Marko Kovacevic
---
doc/guides/sample_app_ug/ip_pipeline.rst | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/doc
Hi,
First, I think your question should be sent to the user mailing list, not
the dev mailing list.
> I have seen that each packet has a headroom memory space (128 bytes long)
> where RSS hashing and other metadata provided by the NIC is stored.
If I'm not mistaken, the headroom is not where met
Hi all,
Victor, I suggest taking a closer look at section 7.1. here:
http://dpdk.org/doc/guides/prog_guide/mbuf_lib.html
The approach chosen by DPDK is to store everything, metadata and packet data,
in contiguous memory. That way, network packets will always have 1 to 1
relationship with DPDK m
Hi everybody,
I know this thread was from over 2 years ago but I ran into the same problem
with l3fwd-power today.
Any updates on this?
-BL
Forgot to link the original thread.
http://dpdk.org/ml/archives/dev/2016-January/030930.html
-BL
> -Original Message-
> From: long...@viettel.com.vn [mailto:long...@viettel.com.vn]
> Sent: Friday, March 2, 2018 2:19 PM
> To: dev@dpdk.org
> Cc: david.h...@intel.com; mh...@mhcomputing.net;
Hi Dave,
Actually in my test lab which is a HP box running CentOS 7 on kernel version
3.10.0-693.5.2.el7.x86_64, the default cpufreq driver is pcc_cpufreq. So I
guess
disabling intel_pstate wouldn't help in my case.
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
pcc-cpufreq
# cat /s
Hi Dave,
Unfortunately I do not have access to our server BIOS settings. The power
management task for our appliance is also on pending. I'm expecting to return
to this task in April. Maybe we can still work out a patch before 18.05 (not
sure about DPDK roadmap).
Regards,
-BL
> -Original
The RX and TX Prefetch, Host, and Write-back threshold values are
defined but not used anywhere. They are leftovers from a previous
patch.
Fixes: 81f7ecd9 ("examples: use factorized default Rx/Tx configuration")
Cc: sta...@dpdk.org
Signed-off-by: Bao-Long Tran
---
examples/l3fwd-vf/main.c | 19
The Rx/Tx configuration was updated in this commit
81f7ecd9 ("examples: use factorized default Rx/Tx configuration")
The patch set remove some leftovers from that commit.
Bao-Long Tran (2):
examples/l3fwd-vf: remove old Rx/Tx configuration defines
doc: remove old Rx/Tx configuration info in l
Update doc the match with code.
Fixes: 81f7ecd9 ("examples: use factorized default Rx/Tx configuration")
Cc: sta...@dpdk.org
Signed-off-by: Bao-Long Tran
---
doc/guides/sample_app_ug/l2_forward_real_virtual.rst | 12
1 file changed, 12 deletions(-)
diff --git a/doc/guides/sample_a
24 matches
Mail list logo
