[dpdk-dev] [PATCH v2] eal/windows: fix invalid thread handle
Casting thread ID to handle is not accurate way to get thread handle.
Need to use OpenThread function to get thread handle from thread ID.
pthread_setaffinity_np and pthread_getaffinity_np functions
for Windows are affected because of it.
Signed-off-by: Tasnim Bashar
---
lib/librte_eal/windows/include/pthread.h | 56
lib/librte_eal/windows/include/rte_windows.h | 1 +
2 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/lib/librte_eal/windows/include/pthread.h
b/lib/librte_eal/windows/include/pthread.h
index 0bbed5c3b8..88dab36b79 100644
--- a/lib/librte_eal/windows/include/pthread.h
+++ b/lib/librte_eal/windows/include/pthread.h
@@ -16,8 +16,8 @@
extern "C" {
#endif
-#include
#include
+#include
#define PTHREAD_BARRIER_SERIAL_THREAD TRUE
@@ -41,31 +41,67 @@ typedef SYNCHRONIZATION_BARRIER pthread_barrier_t;
#define pthread_self() \
((pthread_t)GetCurrentThreadId())
#define pthread_setaffinity_np(thread, size, cpuset) \
- eal_set_thread_affinity_mask(thread, (unsigned long *) cpuset)
+ eal_set_thread_affinity_mask(thread, (long long *) cpuset)
#define pthread_getaffinity_np(thread, size, cpuset) \
- eal_get_thread_affinity_mask(thread, (unsigned long *) cpuset)
+ eal_get_thread_affinity_mask(thread, (long long *) cpuset)
#define pthread_create(threadid, threadattr, threadfunc, args) \
eal_create_thread(threadid, threadfunc, args)
static inline int
-eal_set_thread_affinity_mask(pthread_t threadid, unsigned long *cpuset)
+eal_set_thread_affinity_mask(pthread_t threadid, long long *cpuset)
{
- SetThreadAffinityMask((HANDLE) threadid, *cpuset);
+ DWORD_PTR ret;
+ HANDLE thread_handle;
+
+ thread_handle = OpenThread(THREAD_ALL_ACCESS, FALSE, threadid);
+ if (thread_handle == NULL) {
+ RTE_LOG_WIN32_ERR("OpenThread()");
+ return -1;
+ }
+
+ ret = SetThreadAffinityMask(thread_handle, *cpuset);
+ if (ret == 0) {
+ RTE_LOG_WIN32_ERR("SetThreadAffinityMask()");
+ CloseHandle(thread_handle);
+ return -1;
+ }
+ CloseHandle(thread_handle);
return 0;
}
static inline int
-eal_get_thread_affinity_mask(pthread_t threadid, unsigned long *cpuset)
+eal_get_thread_affinity_mask(pthread_t threadid, long long *cpuset)
{
/* Workaround for the lack of a GetThreadAffinityMask()
*API in Windows
*/
- /* obtain previous mask by setting dummy mask */
- DWORD dwprevaffinitymask =
- SetThreadAffinityMask((HANDLE) threadid, 0x1);
+ DWORD_PTR dwprevaffinitymask;
+ HANDLE thread_handle;
+ DWORD_PTR ret;
+
+ thread_handle = OpenThread(THREAD_ALL_ACCESS, FALSE, threadid);
+ if (thread_handle == NULL) {
+ RTE_LOG_WIN32_ERR("OpenThread()");
+ return -1;
+ }
+
+ /* obtain previous mask by setting dummy mask */
+ dwprevaffinitymask = SetThreadAffinityMask(thread_handle, 0x1);
+ if (dwprevaffinitymask == 0) {
+ RTE_LOG_WIN32_ERR("SetThreadAffinityMask()");
+ CloseHandle(thread_handle);
+ return -1;
+ }
+
/* set it back! */
- SetThreadAffinityMask((HANDLE) threadid, dwprevaffinitymask);
+ ret = SetThreadAffinityMask(thread_handle, dwprevaffinitymask);
+ if (ret == 0) {
+ RTE_LOG_WIN32_ERR("SetThreadAffinityMask()");
+ CloseHandle(thread_handle);
+ return -1;
+ }
*cpuset = dwprevaffinitymask;
+ CloseHandle(thread_handle);
return 0;
}
diff --git a/lib/librte_eal/windows/include/rte_windows.h
b/lib/librte_eal/windows/include/rte_windows.h
index ed6e4c1485..677b63c42d 100644
--- a/lib/librte_eal/windows/include/rte_windows.h
+++ b/lib/librte_eal/windows/include/rte_windows.h
@@ -29,6 +29,7 @@
#define INITGUID
#endif
#include
+#include
/**
* Log GetLastError() with context, usually a Win32 API function and arguments.
--
2.19.1.windows.1
Re: [dpdk-dev] [PATCH] net/bnxt: allow the mark to use a cfa code of zero
On Fri, May 22, 2020 at 4:55 PM Mike Baucom
wrote:
> The mark code was too restrictive by disallowing a cfa_code of zero.
> This code loosens the requirement and allows zero.
>
> Fixes: b87abb2e55cb ("net/bnxt: support marking packet")
>
> Signed-off-by: Mike Baucom
> Reviewed-by: Kishore Padmanabha
>
Applied to dpdk-next-net-brcm with updated commit headline [1].
[1] net/bnxt: fix mark action
> ---
> drivers/net/bnxt/bnxt_rxr.c | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/bnxt/bnxt_rxr.c b/drivers/net/bnxt/bnxt_rxr.c
> index ee1acb1..91ff729 100644
> --- a/drivers/net/bnxt/bnxt_rxr.c
> +++ b/drivers/net/bnxt/bnxt_rxr.c
> @@ -465,17 +465,15 @@ static inline struct rte_mbuf *bnxt_tpa_end(
> break;
> }
>
> - if (cfa_code) {
> - rc = ulp_mark_db_mark_get(bp->ulp_ctx, gfid,
> - cfa_code, &mark_id);
> - if (!rc) {
> - /* Got the mark, write it to the mbuf and return */
> - mbuf->hash.fdir.hi = mark_id;
> - mbuf->udata64 = (cfa_code & 0xull) << 32;
> - mbuf->hash.fdir.id = rxcmp1->cfa_code;
> - mbuf->ol_flags |= PKT_RX_FDIR | PKT_RX_FDIR_ID;
> - return;
> - }
> + rc = ulp_mark_db_mark_get(bp->ulp_ctx, gfid,
> + cfa_code, &mark_id);
> + if (!rc) {
> + /* Got the mark, write it to the mbuf and return */
> + mbuf->hash.fdir.hi = mark_id;
> + mbuf->udata64 = (cfa_code & 0xull) << 32;
> + mbuf->hash.fdir.id = rxcmp1->cfa_code;
> + mbuf->ol_flags |= PKT_RX_FDIR | PKT_RX_FDIR_ID;
> + return;
> }
>
> skip_mark:
> --
> 1.9.1
>
>
Re: [dpdk-dev] [PATCH v5] doc: update bnxt guide
On Thu, May 21, 2020 at 6:51 AM Ferruh Yigit wrote: > On 5/21/2020 2:16 AM, Ajit Khaparde wrote: > > On Wed, May 20, 2020 at 1:04 PM Ajit Khaparde < > ajit.khapa...@broadcom.com> > > wrote: > > > >> - Update list of supported adapters. > >> - Update list of supported features. > >> - Add some details to describe the features. > >> - Remove obsolete limitations. > >> - Fix and update links. > >> > >> Signed-off-by: JP Lee > >> Signed-off-by: Ajit Khaparde > >> Acked-by: Kovacevic Marko > >> --- > >> v1->v2: Some lines were too long in v1. Made then shorter. Checked for > >> typos. > >> v2->v3: Removed list of extended stats. > >> v3->v4: Removed an irrelevant line. > >> v4->v5: Shorten the long lines further. > >> > > > > Applied to dpdk-next-net-brcm. Thanks > Ferruh, This looks good. Thanks
Re: [dpdk-dev] [PATCH v2 0/2] fix MAC ctrl frame fwd get
Reviewed-by: Wei Zhao > -Original Message- > From: Sun, GuinanX > Sent: Saturday, May 23, 2020 1:23 PM > To: dev@dpdk.org > Cc: Zhao1, Wei ; Yang, Qiming > ; Sun, GuinanX > Subject: [PATCH v2 0/2] fix MAC ctrl frame fwd get > > Fix incorrect MAC control frame forward. > Fix flow control status get. > --- > v2 changes: > * Rebase. > * Split into two patches. > * Set fc mac_ctrl_frame_fwd by bit operation. > * Modify commit messge. > > Guinan Sun (2): > net/ixgbe: fix incorrect MAC control frame forward > net/ixgbe: fix flow control status get > > drivers/net/ixgbe/ixgbe_ethdev.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > -- > 2.17.1
[dpdk-dev] [PATCH] eal: fix memory leak in uevent parse and process
From: Yunjian Wang
When the memory for uevent.devname is allocated in dev_uev_parse(). It
is not freed when parse the subsystem layer fails in dev_uev_parse().
And Before return, it is also not freed in dev_uev_handler(). These
cause a memory leak.
Fixes: 0d0f478d0483 ("eal/linux: add uevent parse and process")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
lib/librte_eal/linux/eal_dev.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linux/eal_dev.c b/lib/librte_eal/linux/eal_dev.c
index 83c9cd660..3a2bf8514 100644
--- a/lib/librte_eal/linux/eal_dev.c
+++ b/lib/librte_eal/linux/eal_dev.c
@@ -189,7 +189,7 @@ dev_uev_parse(const char *buf, struct rte_dev_event *event,
int length)
else if (!strncmp(subsystem, "vfio", 4))
event->subsystem = EAL_DEV_EVENT_SUBSYSTEM_VFIO;
else
- return -1;
+ goto out;
/* parse the action type */
if (!strncmp(action, "add", 3))
@@ -197,8 +197,12 @@ dev_uev_parse(const char *buf, struct rte_dev_event
*event, int length)
else if (!strncmp(action, "remove", 6))
event->type = RTE_DEV_EVENT_REMOVE;
else
- return -1;
+ goto out;
return 0;
+out:
+ if (event->devname)
+ free(event->devname);
+ return -1;
}
static void
@@ -277,12 +281,14 @@ dev_uev_handler(__rte_unused void *param)
rte_spinlock_unlock(&failure_handle_lock);
}
rte_dev_event_callback_process(uevent.devname, uevent.type);
+ free(uevent.devname);
}
return;
failure_handle_err:
rte_spinlock_unlock(&failure_handle_lock);
+ free(uevent.devname);
}
int
--
2.23.0
[dpdk-dev] [PATCH] test-pmd: fix memory leaks when mtr policer actions update fails
From: Yunjian Wang
Fix memory leaks reported by Coverity.
Fixes: e63b50162aa3 ("app/testpmd: clean metering and policing commands")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
app/test-pmd/cmdline_mtr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index caa7e9864..ee16244de 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -1262,6 +1262,7 @@ static void cmd_set_port_meter_policer_action_parsed(void
*parsed_result,
ret = rte_mtr_policer_actions_update(port_id, mtr_id,
action_mask, actions, &error);
if (ret != 0) {
+ free(actions);
print_err_msg(&error);
return;
}
--
2.23.0
[dpdk-dev] [PATCH] doc: announce the deprecation of legacy virtio support
From: Jerin Jacob The legacy virtio is not architecture agnostics. It relies on x86 IO port scheme support for its working. The legacy virtio is only the consumer of RTE_KDRV_NONE in the DPDK PCI subsystem. Legacy virtio deprecation will also optimize DPDK PCI enumeration management as it does not need to probe RTE_KDRV_NONE based devices anymore. Deprecation is planned for v20.08 release. More details at http://patches.dpdk.org/patch/69351/ Cc: maxime.coque...@redhat.com Cc: david.march...@redhat.com Signed-off-by: Jerin Jacob --- doc/guides/rel_notes/deprecation.rst | 8 1 file changed, 8 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index cf8b1eb7b..d2907e32f 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -107,3 +107,11 @@ Deprecation Notices Python 2 support will be completely removed in 20.11. In 20.08, explicit deprecation warnings will be displayed when running scripts with Python 2. + +* virtio: The legacy virtio is not architecture agnostics. + It relies on x86 IO port scheme support for its working. + The legacy virtio is only the consumer of RTE_KDRV_NONE in DPDK PCI subsystem. + Legacy virtio deprecation will also optimize DPDK PCI enumeration management as + it does not need to probe RTE_KDRV_NONE based devices anymore. + Deprecation is planned for v20.08 release. + More details at http://patches.dpdk.org/patch/69351/ -- 2.26.2
Re: [dpdk-dev] incorrect vlan_tci in rte mbuf
Hi,
I tried the change, and it solved the problem.
Should I submit the change to github? Or you will do that?
Thank you.
Best regards
Yan Xiaoping
-Original Message-
From: Zhang, Qi Z
Sent: 2020年5月19日 20:42
To: Yan, Xiaoping (NSB - CN/Hangzhou) ; Guo, Jia
; Xing, Beilei
Cc: dev@dpdk.org; Olivier Matz
Subject: RE: [dpdk-dev] incorrect vlan_tci in rte mbuf
Hi Xiaoping:
According to i40e datasheet, for packet with multiple buffer, the L2TAG
should only be valid on last Rx descriptor.
So it is identical with what you observed and it looks like a bug in
the vector path.
Could you try if below change can fix the issue?
--- a/drivers/net/i40e/i40e_rxtx_vec_common.h
+++ b/drivers/net/i40e/i40e_rxtx_vec_common.h
@@ -34,6 +34,7 @@ reassemble_packets(struct i40e_rx_queue *rxq, struct rte_mbuf
**rx_bufs,
/* it's the last packet of the set */
start->hash = end->hash;
start->ol_flags = end->ol_flags;
+ start->vlan_tci = end->vlan_tci;
/* we need to strip crc for the whole packet */
start->pkt_len -= rxq->crc_len;
if (end->data_len > rxq->crc_len
Thanks
Qi
> -Original Message-
> From: dev On Behalf Of Yan, Xiaoping (NSB -
> CN/Hangzhou)
> Sent: Tuesday, May 19, 2020 4:32 PM
> To: Guo, Jia ; Xing, Beilei
> Cc: dev@dpdk.org; Olivier Matz
> Subject: Re: [dpdk-dev] incorrect vlan_tci in rte mbuf
>
> Hi,
>
> I tried to use gdb to print the rx descriptor, and it turned out that
> only the rxd for the last segment has correct l2tag1 value.
> Test step: ping xx.xx.xx.xx -s 2500, from a vlan interface with vlan id
> 1901,
> MTU 9000. (this will sends 1 packet, and needs two mbuf segments to
> receive, length of 1st mbuf segment is 2176(mbuf size of my dpdk
> application), length of 2nd mbuf segment is 366)
>
> Rx descriptor printed with gdb:
> Breakpoint 2 at 0x75efa4bb: file
> /usr/src/debug/dpdk-18.11.1-2.nok6.wf31.x86_64/package/dpdk/dpdk-18.1
> 1/drivers/net/i40e/i40e_rxtx_vec_avx2.c, line 496.
> (gdb) print *(rxq->rx_ring + rxq->rx_tail+1)
> $4 = {read = {pkt_addr = 14858615587319906304, hdr_addr =
> 598164390293517, rsvd1 = 0,
> rsvd2 = 0}, wb = {qword0 = {lo_dword = {mirr_fcoe =
> {mirroring_status = 0,
> fcoe_ctx_id = 0}, l2tag1 = 73}, hi_dword = {rss = 3459541031,
> fcoe_param = 3459541031, fd_id = 3459541031}}, qword1 = {
> status_error_len = 598164390293517}, qword2 = {ext_status = 0,
> rsvd = 0,
> l2tag2_1 = 0, l2tag2_2 = 0}, qword3 = {lo_dword = {flex_bytes_lo = 0,
> pe_status = 0}, hi_dword = {flex_bytes_hi = 0, fd_id = 0
> (gdb) print *(rxq->rx_ring + rxq->rx_tail+2)
> $5 = {read = {pkt_addr = 14858615587439706112, hdr_addr =
> 100635378724879, rsvd1 = 0,
> rsvd2 = 0}, wb = {qword0 = {lo_dword = {mirr_fcoe =
> {mirroring_status = 0,
> fcoe_ctx_id = 0}, l2tag1 = 1901}, hi_dword = {rss = 3459541031,
> fcoe_param = 3459541031, fd_id = 3459541031}}, qword1 = {
> status_error_len = 100635378724879}, qword2 = {ext_status = 0,
> rsvd = 0,
> l2tag2_1 = 0, l2tag2_2 = 0}, qword3 = {lo_dword = {flex_bytes_lo = 0,
> pe_status = 0}, hi_dword = {flex_bytes_hi = 0, fd_id = 0
>
> With formula: length = (qword1 &
> I40E_RXD_QW1_LENGTH_PBUF_MASK) >>
> I40E_RXD_QW1_LENGTH_PBUF_SHIFT; (qword1 is status_error_len in gdb
> printout)
> I can get length of first segment(rxq->rx_ring + rxq->rx_tail+1) is
> 2176, and length of second segment(rxq->rx_ring + rxq->rx_tail+2) is
> 366, which proves they are the mbuf segments to receive.
> However we can see the l2tag1 of first segment is 73(invalid), l2tag1
> of second segment is 1901(valid).
>
> It means either HW should be modified to fill l2tag1 correctly for
> each every segment, or _recv_raw_pkts_vec_avx2 should be modified to
> read l2tag1 of last segment?
> PS: it seems i40e_recv_scattered_pkts use the l2tag1 of last rxd (to
> set vlan tci of first segment), don't know it is by accident(convenience) or
> by purpose.
>
> Do you agree on my analysis?
> If my analysis is correct, is it possible for you to help make a sw
> patch, because I'm not familiar with this vec avx code.
>
> Best regards
> Yan Xiaoping
>
> -Original Message-
> From: Jeff Guo
> Sent: 2020年5月19日 15:00
> To: Yan, Xiaoping (NSB - CN/Hangzhou) ;
> beilei.x...@intel.com
> Cc: dev@dpdk.org; Olivier Matz
> Subject: Re: [dpdk-dev] incorrect vlan_tci in rte mbuf
>
> hi, xiaoping
>
> On 5/18/2020 4:31 PM, Yan, Xiaoping (NSB - CN/Hangzhou) wrote:
> > Hi Beilei & Jia,
> >
> > I got your name from the MAINTAINERS for Intel i40e.
> > Could you help to have a look at the issue, described in my previous mail?
> >
> > Thank you.
> >
> > Best regards
> > Yan Xiaoping
> >
> > -Original Message-
> > From: Olivi
[dpdk-dev] [PATCH 2/2] net/pcap: add TODO for writing Tx HW timestamp
In order to write a packet with hardware timestamp enabled into a
PCAP file, we need to convert its device specific raw timestamp first.
This might not be trivial since querying the raw clock value from
the device is still experimental, and derivating the frequency would
ideally require an additional alarm thread.
As a first step, pass the mbuf to the timestamp calculation function
since mbuf->port and mbuf->timestamp would be needed, and add a TODO
note. No functional changes.
Signed-off-by: Vivien Didelot
---
drivers/net/pcap/rte_eth_pcap.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index 68588c3d7..f205a28e0 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -290,10 +290,16 @@ eth_null_rx(void *queue __rte_unused,
#define NSEC_PER_SEC 1e9
static inline void
-calculate_timestamp(struct timeval *ts) {
+calculate_timestamp(const struct rte_mbuf *mbuf, struct timeval *ts) {
uint64_t cycles;
struct timeval cur_time;
+ if (mbuf->ol_flags & PKT_RX_TIMESTAMP) {
+ /* TODO: convert mbuf->timestamp into nanoseconds instead.
+ * See rte_eth_read_clock().
+ */
+ }
+
cycles = rte_get_timer_cycles() - start_cycles;
cur_time.tv_sec = cycles / hz;
cur_time.tv_usec = (cycles % hz) * NSEC_PER_SEC / hz;
@@ -339,7 +345,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs,
uint16_t nb_pkts)
caplen = sizeof(temp_data);
}
- calculate_timestamp(&header.ts);
+ calculate_timestamp(mbuf, &header.ts);
header.len = len;
header.caplen = caplen;
/* rte_pktmbuf_read() returns a pointer to the data directly
--
2.26.2
Re: [dpdk-dev] net/i40e: fix error setting for L2TAG
Hi,
In which dpdk release, this fix will be available?
Thank you.
Best regards
Yan Xiaoping
-Original Message-
From: Ye Xiaolong
Sent: 2020年5月21日 8:23
To: Jeff Guo
Cc: beilei.x...@intel.com; qi.z.zh...@intel.com; jianbo@linaro.org; Yan,
Xiaoping (NSB - CN/Hangzhou) ; dev@dpdk.org;
olivier.m...@6wind.com
Subject: Re: [dpdk-dev] net/i40e: fix error setting for L2TAG
On 05/20, Jeff Guo wrote:
>Base on HW, if a packet be split into multiple segments, the L2TAG
>should only be valid on the last Rx descriptor. So fix it by setting
>L2TAG into mbuf when processing the last split packet.
>
>Fixes: ca74903b75cf ("net/i40e: extract non-x86 specific code from
>vector driver")
>
>Signed-off-by: Jeff Guo
>---
> drivers/net/i40e/i40e_rxtx_vec_common.h | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/drivers/net/i40e/i40e_rxtx_vec_common.h
>b/drivers/net/i40e/i40e_rxtx_vec_common.h
>index 0e6ffa007..31f73f605 100644
>--- a/drivers/net/i40e/i40e_rxtx_vec_common.h
>+++ b/drivers/net/i40e/i40e_rxtx_vec_common.h
>@@ -33,6 +33,7 @@ reassemble_packets(struct i40e_rx_queue *rxq, struct
>rte_mbuf **rx_bufs,
> if (!split_flags[buf_idx]) {
> /* it's the last packet of the set */
> start->hash = end->hash;
>+ start->vlan_tci = end->vlan_tci;
> start->ol_flags = end->ol_flags;
> /* we need to strip crc for the whole packet */
> start->pkt_len -= rxq->crc_len;
>--
>2.20.1
>
Applied to dpdk-next-net-intel, Thanks.
[dpdk-dev] [PATCH 1/2] net/pcap: support software Tx nanosecond timestamp
When capturing packets into a PCAP file, DPDK currently uses
microseconds for the timestamp. But libpcap supports interpreting
tv_usec as nanoseconds depending on the file timestamp precision.
To support this, use PCAP_TSTAMP_PRECISION_NANO when creating the
empty PCAP file as specified by PCAP_OPEN_DEAD(3PCAP) and implement
nanosecond timeval addition. This also ensures that the precision
reported by capinfos is nanoseconds (9).
Signed-off-by: Vivien Didelot
---
drivers/net/pcap/rte_eth_pcap.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index b4c79d174..68588c3d7 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -287,6 +287,8 @@ eth_null_rx(void *queue __rte_unused,
return 0;
}
+#define NSEC_PER_SEC 1e9
+
static inline void
calculate_timestamp(struct timeval *ts) {
uint64_t cycles;
@@ -294,8 +296,14 @@ calculate_timestamp(struct timeval *ts) {
cycles = rte_get_timer_cycles() - start_cycles;
cur_time.tv_sec = cycles / hz;
- cur_time.tv_usec = (cycles % hz) * 1e6 / hz;
- timeradd(&start_time, &cur_time, ts);
+ cur_time.tv_usec = (cycles % hz) * NSEC_PER_SEC / hz;
+
+ ts->tv_sec = start_time.tv_sec + cur_time.tv_sec;
+ ts->tv_usec = start_time.tv_usec + cur_time.tv_usec;
+ if (ts->tv_usec > NSEC_PER_SEC) {
+ ts->tv_usec -= NSEC_PER_SEC;
+ ts->tv_sec += 1;
+ }
}
/*
@@ -475,7 +483,8 @@ open_single_tx_pcap(const char *pcap_filename,
pcap_dumper_t **dumper)
* with pcap_dump_open(). We create big enough an Ethernet
* pcap holder.
*/
- tx_pcap = pcap_open_dead(DLT_EN10MB, RTE_ETH_PCAP_SNAPSHOT_LEN);
+ tx_pcap = pcap_open_dead_with_tstamp_precision(DLT_EN10MB,
+ RTE_ETH_PCAP_SNAPSHOT_LEN, PCAP_TSTAMP_PRECISION_NANO);
if (tx_pcap == NULL) {
PMD_LOG(ERR, "Couldn't create dead pcap");
return -1;
--
2.26.2
Re: [dpdk-dev] [PATCH 20.08 9/9] config/arm: support python3 only
22/05/2020 16:10, Kilheeney, Louise: > From: Thomas Monjalon > > 22/05/2020 15:23, Louise Kilheeney: > > > Changed script to explicitly use python3 only. > > > > What is the reason of this change? > > since python 2 is EOL, Making these scripts to use python3-only, > it's part of a general update to have everything use python3. > This is already using python 3 and this makes it explicit. This is to avoid maintaining python 2 compatibility I guess. Please insert this real reason in the git commit log. > > --- a/config/arm/armv8_machine.py > > +++ b/config/arm/armv8_machine.py > > @@ -1,4 +1,4 @@ > > -#!/usr/bin/python > > +#!/usr/bin/python3 Are you sure all OS have /usr/bin/python3? Is it called "python" sometimes? Is it always located in /usr/bin/? Shouldn't we use "#! /usr/bin/env python3" ?
Re: [dpdk-dev] [PATCH 2/2] net/pcap: add TODO for writing Tx HW timestamp
On Sat, 23 May 2020 13:21:30 -0400
Vivien Didelot wrote:
> In order to write a packet with hardware timestamp enabled into a
> PCAP file, we need to convert its device specific raw timestamp first.
>
> This might not be trivial since querying the raw clock value from
> the device is still experimental, and derivating the frequency would
> ideally require an additional alarm thread.
>
> As a first step, pass the mbuf to the timestamp calculation function
> since mbuf->port and mbuf->timestamp would be needed, and add a TODO
> note. No functional changes.
>
> Signed-off-by: Vivien Didelot
> ---
> drivers/net/pcap/rte_eth_pcap.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
> index 68588c3d7..f205a28e0 100644
> --- a/drivers/net/pcap/rte_eth_pcap.c
> +++ b/drivers/net/pcap/rte_eth_pcap.c
> @@ -290,10 +290,16 @@ eth_null_rx(void *queue __rte_unused,
> #define NSEC_PER_SEC 1e9
>
> static inline void
> -calculate_timestamp(struct timeval *ts) {
> +calculate_timestamp(const struct rte_mbuf *mbuf, struct timeval *ts) {
> uint64_t cycles;
> struct timeval cur_time;
>
> + if (mbuf->ol_flags & PKT_RX_TIMESTAMP) {
> + /* TODO: convert mbuf->timestamp into nanoseconds instead.
> + * See rte_eth_read_clock().
> + */
> + }
> +
> cycles = rte_get_timer_cycles() - start_cycles;
> cur_time.tv_sec = cycles / hz;
> cur_time.tv_usec = (cycles % hz) * NSEC_PER_SEC / hz;
> @@ -339,7 +345,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs,
> uint16_t nb_pkts)
> caplen = sizeof(temp_data);
> }
>
> - calculate_timestamp(&header.ts);
> + calculate_timestamp(mbuf, &header.ts);
> header.len = len;
> header.caplen = caplen;
> /* rte_pktmbuf_read() returns a pointer to the data directly
> --
NAK
What is the point of this patch.
Most projects do not accept speculative patches. Instead incorporate this
patch in when you have code that uses it.
Re: [dpdk-dev] [PATCH 1/2] net/pcap: support software Tx nanosecond timestamp
On Sat, 23 May 2020 13:21:29 -0400
Vivien Didelot wrote:
> When capturing packets into a PCAP file, DPDK currently uses
> microseconds for the timestamp. But libpcap supports interpreting
> tv_usec as nanoseconds depending on the file timestamp precision.
>
> To support this, use PCAP_TSTAMP_PRECISION_NANO when creating the
> empty PCAP file as specified by PCAP_OPEN_DEAD(3PCAP) and implement
> nanosecond timeval addition. This also ensures that the precision
> reported by capinfos is nanoseconds (9).
>
> Signed-off-by: Vivien Didelot
> ---
> drivers/net/pcap/rte_eth_pcap.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
> index b4c79d174..68588c3d7 100644
> --- a/drivers/net/pcap/rte_eth_pcap.c
> +++ b/drivers/net/pcap/rte_eth_pcap.c
> @@ -287,6 +287,8 @@ eth_null_rx(void *queue __rte_unused,
> return 0;
> }
>
> +#define NSEC_PER_SEC 1e9
> +
> static inline void
> calculate_timestamp(struct timeval *ts) {
> uint64_t cycles;
> @@ -294,8 +296,14 @@ calculate_timestamp(struct timeval *ts) {
>
> cycles = rte_get_timer_cycles() - start_cycles;
> cur_time.tv_sec = cycles / hz;
> - cur_time.tv_usec = (cycles % hz) * 1e6 / hz;
> - timeradd(&start_time, &cur_time, ts);
> + cur_time.tv_usec = (cycles % hz) * NSEC_PER_SEC / hz;
> +
> + ts->tv_sec = start_time.tv_sec + cur_time.tv_sec;
> + ts->tv_usec = start_time.tv_usec + cur_time.tv_usec;
> + if (ts->tv_usec > NSEC_PER_SEC) {
> + ts->tv_usec -= NSEC_PER_SEC;
> + ts->tv_sec += 1;
> + }
Please no floating point math in the fast path of capturing packets!
Re: [dpdk-dev] net/iavf: fix protocol field selector configure
hi, qi
On 5/23/2020 10:03 AM, Zhang, Qi Z wrote:
-Original Message-
From: Guo, Jia
Sent: Saturday, May 23, 2020 7:18 AM
To: Xing, Beilei ; Zhang, Qi Z ;
Wu, Jingjing
Cc: Ye, Xiaolong ; dev@dpdk.org; Guo, Jia
Subject: [dpdk-dev] net/iavf: fix protocol field selector configure
When VFs configure the rss rule by virtchnl, it need to set bit mask into the
field selector for the protocol, then PF got the configure massage and parse
the field selector to the corresponding protocol field.
Fixes: 7be10c3004be ("net/iavf: add RSS configuration for VF")
Signed-off-by: Jeff Guo
---
drivers/net/iavf/iavf_hash.c | 474 +--
1 file changed, 280 insertions(+), 194 deletions(-)
diff --git a/drivers/net/iavf/iavf_hash.c b/drivers/net/iavf/iavf_hash.c index
af528863b..1e0ffad4c 100644
--- a/drivers/net/iavf/iavf_hash.c
+++ b/drivers/net/iavf/iavf_hash.c
@@ -43,6 +43,7 @@ struct iavf_hash_match_type {
enum iavf_pattern_hint_type phint_type;
uint64_t hash_type;
struct virtchnl_proto_hdrs *proto_hdrs;
+ uint32_t link_type;
If this is just a hint for gtpu link type.
Better to rename to "gtpu_hint"
And use the already defined enum but not uint32_t.
ok.
};
struct iavf_rss_meta {
@@ -147,8 +148,11 @@ static struct iavf_pattern_match_item
iavf_hash_pattern_list[] = {
{iavf_pattern_empty, IAVF_INSET_NONE, &phint_empty}, };
-#defineGTP_EH_PDU_LINK_UP 1
-#defineGTP_EH_PDU_LINK_DWN 0
+enum iavf_pattern_link_type {
Rename to iavf_gtpu_hint.
seem it is better.
+ IAVF_PATTERN_LINK_DOWN,
+ IAVF_PATTERN_LINK_UP,
+ IAVF_PATTERN_LINK_NONE,
+};
The configure is for GTP down/up link,
The name "xxx_LINK_DOWN", and "xxx_LINK_UP" is a little bit misleading.
Could be
IAVF_GTPU_HINT_UPLINK.
IAVF_GTPU_HINT_DOWNLINK.
IAVF_GTPU_HINT_N/A
ok, but i will choose IAVF_GTPU_HINT_NONE but not IAVF_GTPU_HINT_N/A
for common and it should also knowledgeable.
#define TUNNEL_LEVEL_OUTER0
#define TUNNEL_LEVEL_FIRST_INNER 1
@@ -160,103 +164,112 @@ static struct iavf_pattern_match_item
iavf_hash_pattern_list[] = {
#define BUFF_NOUSED 0
#define FIELD_FOR_PROTO_ONLY 0
+#define FIELD_SELECTOR(proto_hdr_field)(1UL << ((proto_hdr_field) % \
+(1UL << PROTO_HDR_SHIFT)))
Could be simplified to.
#define FIELD_SELECTOR(proto_hdr_field) \
(1UL << (proto_hdr_field & PROTO_HDR_FIELD_MASK))
Use the currently macro to make it simple, sounds good. Thanks.
..
Regards
Qi
[dpdk-dev] [dpdk-dev v2] net/iavf: fix protocol field selector configure
When VFs configure the rss rule by virtchnl, it need to set bit mask into
the field selector for the protocol, then PF got the configure massage and
parse the field selector to the corresponding protocol field.
Fixes: 7be10c3004be ("net/iavf: add RSS configuration for VF")
Signed-off-by: Jeff Guo
---
drivers/net/iavf/iavf_hash.c | 476 +--
1 file changed, 281 insertions(+), 195 deletions(-)
diff --git a/drivers/net/iavf/iavf_hash.c b/drivers/net/iavf/iavf_hash.c
index af528863b..a7691ef0c 100644
--- a/drivers/net/iavf/iavf_hash.c
+++ b/drivers/net/iavf/iavf_hash.c
@@ -35,6 +35,12 @@ enum iavf_pattern_hint_type {
IAVF_PATTERN_HINT_IPV6_SCTP,
};
+enum iavf_gtpu_hint {
+ IAVF_GTPU_HINT_DOWNLINK,
+ IAVF_GTPU_HINT_UPLINK,
+ IAVF_GTPU_HINT_NONE,
+};
+
struct iavf_pattern_match_type {
enum iavf_pattern_hint_type phint_type;
};
@@ -43,6 +49,7 @@ struct iavf_hash_match_type {
enum iavf_pattern_hint_type phint_type;
uint64_t hash_type;
struct virtchnl_proto_hdrs *proto_hdrs;
+ enum iavf_gtpu_hint gtpu_hint;
};
struct iavf_rss_meta {
@@ -147,9 +154,6 @@ static struct iavf_pattern_match_item
iavf_hash_pattern_list[] = {
{iavf_pattern_empty, IAVF_INSET_NONE, &phint_empty},
};
-#defineGTP_EH_PDU_LINK_UP 1
-#defineGTP_EH_PDU_LINK_DWN 0
-
#define TUNNEL_LEVEL_OUTER 0
#define TUNNEL_LEVEL_FIRST_INNER 1
@@ -160,103 +164,112 @@ static struct iavf_pattern_match_item
iavf_hash_pattern_list[] = {
#define BUFF_NOUSED0
#define FIELD_FOR_PROTO_ONLY 0
+#define FIELD_SELECTOR(proto_hdr_field) \
+ (1UL << ((proto_hdr_field) & PROTO_HDR_FIELD_MASK))
+
#define proto_hint_eth_src { \
- VIRTCHNL_PROTO_HDR_ETH, VIRTCHNL_PROTO_HDR_ETH_SRC, {BUFF_NOUSED } }
+ VIRTCHNL_PROTO_HDR_ETH, FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_ETH_SRC), \
+ {BUFF_NOUSED } }
#define proto_hint_eth_dst { \
- VIRTCHNL_PROTO_HDR_ETH, VIRTCHNL_PROTO_HDR_ETH_DST, {BUFF_NOUSED } }
+ VIRTCHNL_PROTO_HDR_ETH, FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_ETH_DST), \
+ {BUFF_NOUSED } }
#define proto_hint_eth_only { \
VIRTCHNL_PROTO_HDR_ETH, FIELD_FOR_PROTO_ONLY, {BUFF_NOUSED } }
#define proto_hint_eth { \
VIRTCHNL_PROTO_HDR_ETH, \
- VIRTCHNL_PROTO_HDR_ETH_SRC | VIRTCHNL_PROTO_HDR_ETH_DST, \
- {BUFF_NOUSED } }
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_ETH_SRC) | \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_ETH_DST), {BUFF_NOUSED } }
#define proto_hint_svlan { \
- VIRTCHNL_PROTO_HDR_S_VLAN, VIRTCHNL_PROTO_HDR_S_VLAN_ID, \
- {BUFF_NOUSED } }
+ VIRTCHNL_PROTO_HDR_S_VLAN, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_S_VLAN_ID), {BUFF_NOUSED } }
#define proto_hint_cvlan { \
- VIRTCHNL_PROTO_HDR_C_VLAN, VIRTCHNL_PROTO_HDR_C_VLAN_ID, \
- {BUFF_NOUSED } }
+ VIRTCHNL_PROTO_HDR_C_VLAN, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_C_VLAN_ID), {BUFF_NOUSED } }
#define proto_hint_ipv4_src { \
- VIRTCHNL_PROTO_HDR_IPV4, VIRTCHNL_PROTO_HDR_IPV4_SRC, {BUFF_NOUSED } }
+ VIRTCHNL_PROTO_HDR_IPV4, FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_SRC), \
+ {BUFF_NOUSED } }
#define proto_hint_ipv4_dst { \
- VIRTCHNL_PROTO_HDR_IPV4, VIRTCHNL_PROTO_HDR_IPV4_DST, {BUFF_NOUSED } }
+ VIRTCHNL_PROTO_HDR_IPV4, FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_DST), \
+ {BUFF_NOUSED } }
#define proto_hint_ipv4_only { \
VIRTCHNL_PROTO_HDR_IPV4, FIELD_FOR_PROTO_ONLY, {BUFF_NOUSED } }
#define proto_hint_ipv4 { \
VIRTCHNL_PROTO_HDR_IPV4, \
- VIRTCHNL_PROTO_HDR_IPV4_SRC | VIRTCHNL_PROTO_HDR_IPV4_DST, \
- {BUFF_NOUSED } }
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_SRC) | \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_IPV4_DST), {BUFF_NOUSED } }
#define proto_hint_udp_src_port { \
- VIRTCHNL_PROTO_HDR_UDP, VIRTCHNL_PROTO_HDR_UDP_SRC_PORT, \
- {BUFF_NOUSED } }
+ VIRTCHNL_PROTO_HDR_UDP, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_UDP_SRC_PORT), {BUFF_NOUSED } }
#define proto_hint_udp_dst_port { \
- VIRTCHNL_PROTO_HDR_UDP, VIRTCHNL_PROTO_HDR_UDP_DST_PORT, \
- {BUFF_NOUSED } }
+ VIRTCHNL_PROTO_HDR_UDP, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_UDP_DST_PORT), {BUFF_NOUSED } }
#define proto_hint_udp_only { \
VIRTCHNL_PROTO_HDR_UDP, FIELD_FOR_PROTO_ONLY, {BUFF_NOUSED } }
#define proto_hint_udp { \
VIRTCHNL_PROTO_HDR_UDP, \
- VIRTCHNL_PROTO_HDR_UDP_SRC_PORT | VIRTCHNL_PROTO_HDR_UDP_DST_PORT, \
- {BUFF_NOUSED } }
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_UDP_SRC_PORT) | \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_UDP_DST_PORT), {BUFF_NOUSED } }
#define proto_hint_tcp_src_port { \
- VIRTCHNL_PROTO_HDR_TCP, VIRTCHNL_PROTO_HDR_TCP_SRC_PORT, \
- {BUFF_NOUSED } }
+ VIRTCHNL_PROTO_HDR_TCP, \
+ FIELD_SELECTOR(VIRTCHNL_PROTO_HDR_TCP_SRC_PORT), {BU
