Hi,
> -Original Message-
> From: David Marchand
> Sent: Friday, July 26, 2019 7:10 PM
> To: Vamsi Krishna Attunuru
> Cc: dev ; Thomas Monjalon ; Jerin
> Jacob Kollanukkaran ; Aaron Conole
>
> Subject: [EXT] Re: [PATCH v3 1/1] app/test: fix --socket-mem option in eal
> flag
> autotest
>
This patch implements read clock api whose purpose is to return
raw clock ticks. Using this API real time ticks spent in
processing a packet can be known:
- mbuf->timestamp
Calling mbox for reading raw clock ticks in fastpath is very
expensive so its value is derived from time stamp counter(t
A huge drop in per core MPPS value was observed when PTP stack is
enabled. The reason behind the bottleneck is HW serialises the
transfer of all SQEs, which seeks timestamp capture, on the same
send DMA path. Hence only those packets which requires timestamp
capture should set SETTSTAMP in send mem
This patch implements read clock api whose purpose is to return
raw clock ticks. Using this API real time ticks spent in
processing a packet can be known:
- mbuf->timestamp
Calling mbox for reading raw clock ticks in fastpath is very
expensive so its value is derived from time stamp counter(t
A huge drop in per core MPPS value was observed when PTP stack is
enabled. The reason behind the bottleneck is HW serialises the
transfer of all SQEs, which seeks timestamp capture, on the same
send DMA path. Hence only those packets which requires timestamp
capture should set SETTSTAMP in send mem
A huge drop in per core MPPS value was observed when PTP stack is
enabled. The reason behind the bottleneck is HW serialises the
transfer of all SQEs, which seeks timestamp capture, on the same
send DMA path. Hence only those packets which requires timestamp
capture should set SETTSTAMP in send mem
This patch implements read clock api whose purpose is to return
raw clock ticks. Using this API real time ticks spent in
processing a packet can be known:
- mbuf->timestamp
Calling mbox for reading raw clock ticks in fastpath is very
expensive so its value is derived from time stamp counter(t
> -Original Message-
> From: dev On Behalf Of Harman Kalra
> Sent: Thursday, July 25, 2019 9:22 PM
> To: John McNamara ; Pablo de Lara
> ; Bruce Richardson
> ; Harry van Haaren
> ; Xiaoyun Li
> Cc: dev@dpdk.org; Harman Kalra ; barbe...@kth.se
> Subject: [dpdk-dev] [PATCH] examples/rxtx_ca
> -Original Message-
> From: Harman Kalra
> Sent: Saturday, July 27, 2019 8:27 PM
> To: Jerin Jacob Kollanukkaran ; Nithin Kumar
> Dabilpuram ; Vamsi Krishna Attunuru
> ; Kiran Kumar Kokkilagadda
>
> Cc: dev@dpdk.org; Harman Kalra
> Subject: [PATCH 2/2] net/octeontx2: support read clock
A huge drop in per core MPPS value was observed when PTP stack is
enabled. The reason behind the bottleneck is HW serialises the
transfer of all SQEs, which seeks timestamp capture, on the same
send DMA path. Hence only those packets which requires timestamp
capture should set SETTSTAMP in send mem
This patch implements read clock api whose purpose is to return
raw clock ticks. Using this API real time ticks spent in
processing a packet can be known:
- mbuf->timestamp
Signed-off-by: Harman Kalra
---
drivers/common/octeontx2/otx2_mbox.h | 2 +
drivers/net/octeontx2/otx2_ethdev.c | 86
Earlier implementation for enabling ptp via RX offload flag was
causing segmentation fault as it was getting executed in the
device configuration stage where RX and TX queues were not
configured. As in the ptp enable process rx queues are used for
mbuf setup while tx queues are used for send descri
On 7/25/2019 1:50 PM, Sunil Kumar Kori wrote:
> External Email
>
> --
> Multi segmented packet may be spliced with indirect mbufs also.
> Currently driver causes buffer leak for indirect mbufs as they
> were not being freed to pa
> -Original Message-
> From: dev On Behalf Of Harman Kalra
> Sent: Thursday, July 25, 2019 7:55 PM
> To: John McNamara ; Pablo de Lara
> ; Bruce Richardson
> ; Harry van Haaren
> ; Xiaoyun Li
> Cc: dev@dpdk.org; Harman Kalra ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH v2] examples/ptpc
> -Original Message-
> From: Harman Kalra
> Sent: Thursday, July 25, 2019 3:57 PM
> To: Jerin Jacob Kollanukkaran ; Nithin Kumar
> Dabilpuram ; Vamsi Krishna Attunuru
> ; Kiran Kumar Kokkilagadda
>
> Cc: dev@dpdk.org; Harman Kalra
> Subject: [PATCH v2] drivers/octeontx2: fix recursive qi
>-Original Message-
>From: dev On Behalf Of jer...@marvell.com
>Sent: Friday, July 26, 2019 10:55 AM
>To: dev@dpdk.org; Jerin Jacob Kollanukkaran ;
>Nithin Kumar Dabilpuram ; Vamsi Krishna
>Attunuru
>Cc: tho...@monjalon.net
>Subject: [EXT] [dpdk-dev] [PATCH] common/octeontx2: fix to pr
Sort the experimental symbols per release to make it easier/quicker to
check for how long we have them.
Signed-off-by: David Marchand
Acked-by: Ferruh Yigit
---
Changelog since v2:
- fixed alphabetical order per release
Changelog since v1:
- rte_service symbols who got promoted to stable got re
On Fri, Jul 26, 2019 at 6:06 PM Michael Santana Francisco
wrote:
>
> On 7/26/19 10:06 AM, David Marchand wrote:
>
> Sort the experimental symbols per release to make it easier/quicker to
> check for how long we have them.
>
> Signed-off-by: David Marchand
> ---
> Changelog since v1:
> - rte_servi
18 matches
Mail list logo
