Re: [dpdk-dev] [PATCH] l2fwd-event: fix lcore allocation in poll mode
On Mon, Feb 3, 2020 at 10:16 AM wrote:
>
> From: Pavan Nikhilesh
>
> Skip master lcore when assigning cores to rx_queues as it is only used
> to print stats.
>
> Fixes: 4ff457986f76 ("examples/l2fwd-event: add default poll mode routines")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Pavan Nikhilesh
Applied to dpdk-next-eventdev/master. Thanks.
> ---
> examples/l2fwd-event/l2fwd_poll.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/examples/l2fwd-event/l2fwd_poll.c
> b/examples/l2fwd-event/l2fwd_poll.c
> index a3a383558..2033c65e5 100644
> --- a/examples/l2fwd-event/l2fwd_poll.c
> +++ b/examples/l2fwd-event/l2fwd_poll.c
> @@ -116,6 +116,7 @@ l2fwd_poll_lcore_config(struct l2fwd_resources *rsrc)
>
> /* get the lcore_id for this port */
> while (rte_lcore_is_enabled(rx_lcore_id) == 0 ||
> + rx_lcore_id == rte_get_master_lcore() ||
>poll_rsrc->lcore_queue_conf[rx_lcore_id].n_rx_port ==
>rsrc->rx_queue_per_lcore) {
> rx_lcore_id++;
> --
> 2.17.1
>
[dpdk-dev] [pull-request] next-eventdev 20.02 RC3 or RC4
The following changes since commit a0c2b3d8ee501b90eb11c2a82da0aaca19362bd3: drivers/crypto: fix session-less mode (2020-02-13 12:41:21 +0100) are available in the Git repository at: http://dpdk.org/git/next/dpdk-next-eventdev for you to fetch changes up to d80f21aa782a1701dd407334485c09df60f36716: l2fwd-event: fix lcore allocation in poll mode (2020-02-15 13:37:34 +0530) Nipun Gupta (1): event/dpaa2: set number of order sequeuences Pavan Nikhilesh (3): doc: fix service core mask used in l3fwd example app/eventdev: fix test pipeline meson build l2fwd-event: fix lcore allocation in poll mode Sunil Kumar Kori (1): examples/l2fwd-event: fix return value handling from API app/test-eventdev/meson.build| 5 - doc/guides/sample_app_ug/l3_forward.rst | 2 +- drivers/event/dpaa2/dpaa2_eventdev.c | 2 ++ examples/l2fwd-event/l2fwd_event_generic.c | 9 +++-- examples/l2fwd-event/l2fwd_event_internal_port.c | 10 -- examples/l2fwd-event/l2fwd_poll.c| 1 + 6 files changed, 23 insertions(+), 6 deletions(-) [master]dell[dpdk-next-eventdev] $
Re: [dpdk-dev] [PATCH v3] net/i40e: relaxed barrier in the tx fastpath
On Sat, Feb 8, 2020 at 7:22 PM Gavin Hu wrote: > > To keep ordering of mixed accesses, rte_cio is sufficient. > The rte_io barrier is overkill.[1] > > [1] http://inbox.dpdk.org/dev/CALBAE1M-ezVWCjqCZDBw+MMDEC4O9 > qf0kpn89emdgdajepk...@mail.gmail.com > > Signed-off-by: Gavin Hu > --- > V3: > - optimize the barriers in the fast path only, leave as it is for the > barriers in the slow path and control path > - drop the virtio patches from the list as they are in the control path > - it makes more sense to relax the barrier in the fast path, at the PMD level. > relaxing the fundamental rte_io_x barriers APIs requires scrutinizations for > each PMDs which use the barriers directly or indirectly. > V2: > - remove virtio_pci_read/write64 APIs definitions, they are not needed and > generate compiling errors like " error: unused function 'virtio_pci_write64' > [-Werror,-Wunused-function]" > - update the reference link to kernel source code > --- > drivers/net/i40e/i40e_rxtx.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c > index fd1ae80da..8c0f7cc67 100644 > --- a/drivers/net/i40e/i40e_rxtx.c > +++ b/drivers/net/i40e/i40e_rxtx.c > @@ -1248,7 +1248,8 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf > **tx_pkts, uint16_t nb_pkts) >(unsigned) txq->port_id, (unsigned) txq->queue_id, >(unsigned) tx_id, (unsigned) nb_tx); > > - I40E_PCI_REG_WRITE(txq->qtx_tail, tx_id); > + rte_cio_wmb(); > + I40E_PCI_REG_WRITE_RELAXED(txq->qtx_tail, tx_id); Looks good to me from the ARM64 perspective or in general. Reviewed-by: Jerin Jacob > txq->tx_tail = tx_id; > > return nb_tx; > -- > 2.17.1 >
[dpdk-dev] [PATCH] net/octeontx2: fix ptp functionality
PTP functionality has been broken after a change in kernel
where enum npc_kpu_lc_ltype is change to allow adjustment of
LTYPE_MASK to detect all types of IP headers.
Syncing the required changes in DPDK to fix the issue.
Fixes: b5dc3140448e ("net/octeontx2: support base PTP")
Cc: sta...@dpdk.org
Signed-off-by: Harman Kalra
---
drivers/common/octeontx2/hw/otx2_npc.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/common/octeontx2/hw/otx2_npc.h
b/drivers/common/octeontx2/hw/otx2_npc.h
index a0536e0ae..3dfc137a3 100644
--- a/drivers/common/octeontx2/hw/otx2_npc.h
+++ b/drivers/common/octeontx2/hw/otx2_npc.h
@@ -201,7 +201,8 @@ enum npc_kpu_lb_ltype {
};
enum npc_kpu_lc_ltype {
- NPC_LT_LC_IP = 1,
+ NPC_LT_LC_PTP = 1,
+ NPC_LT_LC_IP,
NPC_LT_LC_IP_OPT,
NPC_LT_LC_IP6,
NPC_LT_LC_IP6_EXT,
@@ -209,7 +210,6 @@ enum npc_kpu_lc_ltype {
NPC_LT_LC_RARP,
NPC_LT_LC_MPLS,
NPC_LT_LC_NSH,
- NPC_LT_LC_PTP,
NPC_LT_LC_FCOE,
};
--
2.18.0
Re: [dpdk-dev] L3fwd-power queue utilization issue
On Fri, Feb 14, 2020 at 05:35:53PM +0530, Soumen Chandra Laha wrote: > Hi, > > I'm trying to run l3fwd-power application for 2 Port with queue. Always > only queue 1 of port 0 and port 1 are utilized. > CPU C-state, hpet are enabled, ports are binded to igb_uio. > Tried with NIC's x772 (10 GbE) and XXV710(25 GbE), Observed same behavior. > We have tested l3fwd-power with octeontx2 PMD, l3fwd-power disables queue interrupt even if a single packet is received on the queue. I assume you are pumping multple flows to the nic. > I am observing the below output: > */root/comms/dpdk/examples/l3fwd-power/build/l3fwd-power -l 2,3,4,5 -n 6 > --socket-mem 512,0 -w 17:00.0 -w 17:00.1 -- -p 0x3 --config > '(0,0,2),(0,1,3),(1,0,4),(1,1,5)' -P* > EAL: Detected 48 lcore(s) > EAL: Detected 1 NUMA nodes > EAL: Multi-process socket /var/run/dpdk/l3fwd/mp_socket > EAL: Probing VFIO support... > EAL: PCI device :17:00.0 on NUMA socket 0 > EAL: probe driver: 8086:158b net_i40e > EAL: PCI device :17:00.1 on NUMA socket 0 > EAL: probe driver: 8086:158b net_i40e > Promiscuous mode selected > POWER: Attempting to initialise ACPI cpufreq power management... > POWER: Power management governor of lcore 2 has been set to user space > successfully > POWER: Initialized successfully for lcore 2 power management > POWER: Power management governor of lcore 3 has been set to user space > successfully > POWER: Initialized successfully for lcore 3 power management > POWER: Power management governor of lcore 4 has been set to user space > successfully > POWER: Initialized successfully for lcore 4 power management > POWER: Power management governor of lcore 5 has been set to user space > successfully > POWER: Initialized successfully for lcore 5 power management > Initializing port 0 ... Creating queues: nb_rxq=2 nb_txq=4... Port 0 > modified RSS hash function based on hardware support,requested:0x20820 > configured:0x820 > Address:00:E0:ED:96:2B:AA, Allocated mbuf pool on socket 0 > Initializing rx queues on lcore 2 ... rxq=0,0,0 > Initializing rx queues on lcore 3 ... rxq=0,1,0 > Initializing rx queues on lcore 4 ... rxq=1,0,0 > Initializing rx queues on lcore 5 ... rxq=1,1,0 > > Checking link status.done > Port 0 Link Up - speed 25000 Mbps - full-duplex > Port 1 Link Up - speed 25000 Mbps - full-duplex > L3FWD_POWER: entering main loop on lcore 3 > L3FWD_POWER: -- lcoreid=3 portid=0 rxqueueid=1 > L3FWD_POWER: entering main loop on lcore 4 > L3FWD_POWER: -- lcoreid=4 portid=1 rxqueueid=0 > L3FWD_POWER: entering main loop on lcore 5 > L3FWD_POWER: -- lcoreid=5 portid=1 rxqueueid=1 > EAL: Event already been added. > L3FWD_POWER: entering main loop on lcore 2 > L3FWD_POWER: -- lcoreid=2 portid=0 rxqueueid=0 > EAL: Event already been added. > L3FWD_POWER: lcore 3 sleeps until interrupt triggers > L3FWD_POWER: lcore 4 sleeps until interrupt triggers > L3FWD_POWER: lcore 5 sleeps until interrupt triggers > L3FWD_POWER: lcore 2 sleeps until interrupt triggers > L3FWD_POWER: lcore 3 is waked up from rx interrupt on port 0 queue 1 > L3FWD_POWER: lcore 3 sleeps until interrupt triggers > L3FWD_POWER: lcore 5 is waked up from rx interrupt on port 1 queue 1 > L3FWD_POWER: lcore 5 sleeps until interrupt triggers > > I would appreciate it if some expert can shade a light on this. > > Thanks & Regards, > Soumen
Re: [dpdk-dev] [PATCH v1 1/1] net/octeontx2: fix flow control initial state
On Thu, Feb 6, 2020 at 9:57 AM wrote:
>
> From: Vamsi Attunuru
>
> Currently when application requests for RTE_FC_NONE earlier
> than PMD's internal fc mode update, flow control set routine
> is returning without updating the flow control state.
>
> Patch updates the PMD's internal fc mode details during
> dev_configure to ensure any flow control set requests
> issued later are handled properly.
>
> Fixes: 609945f1ce90 ("net/octeontx2: support flow control")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Vamsi Attunuru
> ---
>
Acked-by: Jerin Jacob
Applied to dpdk-next-net-mrvl/master. Thanks
Re: [dpdk-dev] [PATCH] event/octeontx2: remove WFE from dualslot dequeue
Hi Gavin, >Hi Pavan, > >> -Original Message- >> From: pbhagavat...@marvell.com >> Sent: Friday, February 14, 2020 2:45 PM >> To: jer...@marvell.com; Pavan Nikhilesh > >> Cc: Gavin Hu ; dev@dpdk.org >> Subject: [dpdk-dev] [PATCH] event/octeontx2: remove WFE from >dualslot >> dequeue >> >> From: Pavan Nikhilesh >> >> Each workslot is always bound to a specific lcore there is no multi-core >> contention to cause cache trashing as a result it is safe to remove the >> WFE. Also, in dual workslot dequeue work will mostlikely be available >on >> the pair workslot making WFE impractical. > >Does SSO still signal EVENTI to exit from WFE? Then the core ignore it? All transactions on SSO bus take the core out of WFE. >Can this be disabled as WFE is removed? This can't be disabled. > >> >> Signed-off-by: Pavan Nikhilesh >> --- >> >> Also, this in-turn reduces the branch misses >> >> Before: >> 0 >> >arm_spe_0/ts_enable=1,pct_enable=1,pa_enable=1,branch_filter=1,jit >ter=1, >> min_latency=0/ >> 0 dummy:u >> 0 llc-miss >> 0 tlb-miss >> 853 branch-miss >> 0 remote-access >> 0 l1d-miss >> >> After: >> 0 >> >arm_spe_0/ts_enable=1,pct_enable=1,pa_enable=1,branch_filter=1,jit >ter=1, >> min_latency=0/ >> 0 dummy:u >> 0 llc-miss >> 0 tlb-miss >> 250 branch-miss >> 0 remote-access >> 0 l1d-miss >> >> WFE Data: >> >> 0x4C40 - WFI_WFE_WAIT_CYCLES - Number of cycles waiting at a WFI >or >> WFE instruction. >> >> - WFE Cycles before the patch for Dual workslot >> #perf stat -C 20 -e r4C40 sleep 1 >> Performance counter stats for 'CPU(s) 20': >> >>264 r4C40 >>1.002494168 seconds time elapsed >> >> - WFE Cycles for single workslot >> #perf stat -C 20 -e r4C40 sleep 1 >> Performance counter stats for 'CPU(s) 20': >> >>908,778,351 r4C40 >>1.002598253 seconds time elapsed >> >> drivers/event/octeontx2/otx2_worker_dual.h | 6 +- >> 1 file changed, 1 insertion(+), 5 deletions(-) >> >> diff --git a/drivers/event/octeontx2/otx2_worker_dual.h >> b/drivers/event/octeontx2/otx2_worker_dual.h >> index 5134e3d52..c88420eb4 100644 >> --- a/drivers/event/octeontx2/otx2_worker_dual.h >> +++ b/drivers/event/octeontx2/otx2_worker_dual.h >> @@ -29,11 +29,7 @@ otx2_ssogws_dual_get_work(struct >> otx2_ssogws_state *ws, >> rte_prefetch_non_temporal(lookup_mem); >> #ifdef RTE_ARCH_ARM64 >> asm volatile( >> -"ldr %[tag], [%[tag_loc]]\n" >> -"ldr %[wqp], [%[wqp_loc]]\n" >> -"tbz %[tag], 63, done%= \n" >> -"sevl\n" >> -"rty%=: wfe \n" >> +"rty%=: \n" >> "ldr %[tag], [%[tag_loc]]\n" >> "ldr %[wqp], [%[wqp_loc]]\n" >> "tbnz %[tag], 63, rty%= \n" >> -- >> 2.17.1
Re: [dpdk-dev] [RFC] DPDK Trace support
On Fri, Jan 17, 2020 at 4:24 PM Jerin Jacob wrote:
>
> On Fri, Jan 17, 2020 at 4:00 PM Mattias Rönnblom
> wrote:
> >
>
> > > LTTng kernel tracing only needs kmod support.
> > > For the userspace tracing at minium following libraries are required.
> > >
> > > a) LTTng-UST
> > > b) LTTng-tools
> > > c) liburcu
> > > d) libpopt-dev
> >
> > This "DPDK CTF trace emitter" would make DPDK interoperate with, but
> > without any build-time dependencies to, LTTng. Correct?
>
> Yes. Native CTF trace emitter without LTTng dependency.
>
> >
> > Do you have any idea of what the performance benefits one would receive
> > from having something DPDK native, compared to just depending on LTTng UST?
>
> I calibrated LTTng cost and pushed the test code to github[1].
>
> I just started working on the DPDK native CTF emitter.
> I am sure it will be less than LTTng as we can leverage hugepage, exploit
> dpdk worker thread usage to avoid atomics and use per core variables,
> avoid a lot function pointers in fast-path etc
> I can share the exact overhead after the PoC.
I did the almost feature-complete PoC. The code shared in Github[1]
The documentation and code cleanup etc is still pending.
[1]
https://github.com/jerinjacobk/dpdk-trace.git
trace overhead data on x86:[2]
# 236 cyles with LTTng(>100ns)
# 18 cycles(7ns) with Native DPDK CTF emitter.
trace overhead data on arm64:
# 312 cycles to 1100 cycles with LTTng based on the class of arm64 CPU.
# 11 cycles to 13 cycles with Native DPDK CTF emitter based on the
class of arm64 CPU.
18 cycles(on x86) vs 11 cycles(on arm64) is due to rdtsc() overhead in
x86. It seems rdtsc takes around 15cycles in x86.
# The Native DPDK CTF trace support does not have any dependency on
third-party library.
The generated output file is compatible with LTTng as both are using
CTF trace format.
The performance gain comes from:
1) exploit dpdk worker thread usage model to avoid atomics and use per
core variables
2) use hugepage,
3) avoid a lot function pointers in fast-path etc
4) avoid unaligned store for arm64 etc
Features:
- APIs and Features are similar to rte_log dynamic framework
API(expect log prints on stdout vs it dumps on trace file)
- No specific limit on the events. A string-based event like rte_log
for pattern matching
- Dynamic enable/disable support.
- Instructmention overhead is ~1 cycle. i.e cost of adding the code
wth out using trace feature.
- Timestamp support for all the events using DPDK rte_rtdsc
- No dependency on another library. Cleanroom native implementation of CTF.
Functional test case:
a) echo "trace_autotest" | sudo ./build/app/test/dpdk-test -c 0x3
--trace-level=8
The above command emits the following trace events
uint8_t i;
rte_trace_lib_eal_generic_void();
rte_trace_lib_eal_generic_u64(0x10);
rte_trace_lib_eal_generic_u32(0x1000);
rte_trace_lib_eal_generic_u16(0xffee);
rte_trace_lib_eal_generic_u8(0xc);
rte_trace_lib_eal_generic_i64(-1234);
rte_trace_lib_eal_generic_i32(-1234567);
rte_trace_lib_eal_generic_i16(12);
rte_trace_lib_eal_generic_i8(-3);
rte_trace_lib_eal_generic_string("my string");
rte_trace_lib_eal_generic_function(__func__);
for (i = 0; i < 128; i++)
rte_trace_lib_eal_generic_u8(i);
Install babeltrace package in Linux and point the generated trace file
to babel trace. By default trace file created under
/dpdk-traces/time_stamp/
example:
# babeltrace /root/dpdk-traces/rte-2020-02-15-PM-02-56-51 | more
[13:27:36.138468807] (+?.?) lib.eal.generic.void: { cpu_id =
0, name = "dpdk-test" }, { }
[13:27:36.138468851] (+0.00044) lib.eal.generic.u64: { cpu_id = 0,
name = "dpdk-test" }, { in = 4503599627370496 }
[13:27:36.138468860] (+0.9) lib.eal.generic.u32: { cpu_id = 0,
name = "dpdk-test" }, { in = 268435456 }
[13:27:36.138468934] (+0.00074) lib.eal.generic.u16: { cpu_id = 0,
name = "dpdk-test" }, { in = 65518 }
[13:27:36.138468949] (+0.00015) lib.eal.generic.u8: { cpu_id = 0,
name = "dpdk-test" }, { in = 12 }
[13:27:36.138468956] (+0.7) lib.eal.generic.i64: { cpu_id = 0,
name = "dpdk-test" }, { in = -1234 }
[13:27:36.138468963] (+0.7) lib.eal.generic.i32: { cpu_id = 0,
name = "dpdk-test" }, { in = -1234567 }
[13:27:36.138469024] (+0.00061) lib.eal.generic.i16: { cpu_id = 0,
name = "dpdk-test" }, { in = 12 }
[13:27:36.138469044] (+0.00020) lib.eal.generic.i8: { cpu_id = 0,
name = "dpdk-test" }, { in = -3 }
[13:27:36.138469051] (+0.7) lib.eal.generic.string: { cpu_id =
0, name = "dpdk-test" }, { str = "my string" }
[13:27:36.138469203] (+0.00152) lib.eal.generic.func: { cpu_id =
0, name = "dpdk-test" }, { func = "test_trace_points" }
[13:27:36.138469239] (+0.00036) lib.eal.generic.u8: { cpu_id = 0,
name = "dpdk-test" }, { in = 0 }
[13:27:36.138469246] (+0.7) lib.eal.generic.u8: { cpu_id = 0,
name = "dpdk-test" }, { in = 1 }
[13:2
Re: [dpdk-dev] 17.11.10 (LTS) patches review and test
On Thu, 30 Jan 2020 at 10:08, Luca Boccassi wrote: > > On Mon, 2020-01-13 at 12:47 +, Luca Boccassi wrote: > > Hi all, > > > > Here is a list of patches targeted for LTS release 17.11.10. > > This will be the last 17.11 release. > > > > The planned date for the final release is the 30th of January. > > > > Please help with testing and validation of your use cases and report > > any issues/results with reply-all to this mail. For the final release > > the fixes and reported validations will be added to the release > > notes. > > > > A release candidate tarball can be found at: > > > > > > https://dpdk.org/browse/dpdk-stable/tag/?id=v17.11.10-rc1 > > > > > > These patches are located at branch 17.11 of dpdk-stable repo: > > > > https://dpdk.org/browse/dpdk-stable/ > > > > > > Thanks. > > > > Luca Boccassi > > Hi, > > We are still waiting to solve 2 issues highlighted during validation, > so we need to postpone. > > New proposed target is February the 14th. > > Apologies for any issue it might cause. Hi, The MLX issue has been fixed, but we are still waiting for a resolution for the QAT issue. The release is postponed to the 21st at the earliest. Apologies for any issue it might cause.
Re: [dpdk-dev] [PATCH] event/octeontx2: remove WFE from dualslot dequeue
Reviewed-by: Gavin Hu
Re: [dpdk-dev] [PATCH 1/2] net/qede: Fix VF re-load failure after ungraceful termination of DPDK
On Fri, Feb 7, 2020 at 11:52 AM Rasesh Mody wrote:
>
> +Jerin
>
> >From: dev On Behalf Of Manish Chopra
> >Sent: Thursday, February 06, 2020 12:02 PM
> >
> >On ungraceful termination of DPDK application, PMD VF driver fails to re-load
> >due to PF seeing the VF in unexpected state during VF acquisition handshake.
> >
> >This patch fixes it by allowing VF to request the PF for soft FLR during the
> >load
> >in such cases so that it can get cleanly re-loaded.
> >
> >Fixes: 2ea6f76aff40 ("qede: add core driver")
>
> Cc: sta...@dpdk.org
>
> >
> >Signed-off-by: Manish Chopra
> >Signed-off-by: Shahed Shaikh
> >Signed-off-by: Rasesh Mody
> >---
>
> Acked-by: Rasesh Mody
Fixed following check-git-log.sh warnings[1]
Series applied to dpdk-next-net-mrvl/master. Thanks.
[1]
check-git-log failed
Wrong headline format:
net/qede: Do not stop vport if not started.
Wrong headline uppercase:
net/qede: Fix VF re-load failure after ungraceful termination of DPDK
net/qede: Do not stop vport if not started.
Headline too long:
net/qede: Fix VF re-load failure after ungraceful termination of DPDK
Is it candidate for Cc: sta...@dpdk.org backport?
net/qede: Fix VF re-load failure after ungraceful termination of DPDK]
>
Re: [dpdk-dev] [RFC] meter: fix ABI break due to experimental tag removal
On Fri, Feb 14, 2020 at 09:52:53PM +, Bruce Richardson wrote: > On Fri, Feb 14, 2020 at 03:48:48PM -0500, Neil Horman wrote: > > On Fri, Feb 14, 2020 at 11:36:34AM +, Bruce Richardson wrote: > > > On Thu, Feb 13, 2020 at 09:40:40PM -0500, Neil Horman wrote: > > > > On Thu, Feb 13, 2020 at 05:40:43PM +, Ray Kinsella wrote: > > > > > > > > > > > > > > > On 05/02/2020 11:32, Neil Horman wrote: > > > > > > On Wed, Feb 05, 2020 at 11:04:29AM +0100, Luca Boccassi wrote: > > > > > >> On Tue, 2020-02-04 at 07:02 -0500, Neil Horman wrote: > > > > > But if we can do the versioning in the master, LTS can backport > > > > > it > > > > > and can have mature version of that API in LTS without breaking > > > > > the existing users. > > > > > > > > > > >>> > > > > > >>> But why bother? The only thing you've changed is the version > > > > > >>> tagging. Its ok to leave that alone in LTS, you just cant change > > > > > >>> it. > > > > > >>> > > > > > >>> Thats part of the burden of an LTS release, it will have some > > > > > >>> drift > > > > > >>> from the upstream head, because you have to keep things stable. > > > > > >>> So > > > > > >>> you stabilize the upstream ABI version for this API and just never > > > > > >>> backport it to the current LTS release. > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> A customer (OVS) explicitly and specifically requested backporting > > > > > >> the symbol change to 19.11, as they don't want to enable > > > > > >> experimental APIs in their releases. I replied that it would only > > > > > >> be > > > > > >> acceptable with aliasing to keep compatibility, and Ferruh very > > > > > >> kindly did the work to implement that. > > > > > >> > > > > > > but, thats part of the agreement, no? You can't always have new > > > > > > features and stability at the same time. > > > > > > > > > > > > I get that this is an odd corner case, because strictly speaking you > > > > > > could waive the ABI change that libabigail is reporting, and most > > > > > > application users (like OVS) could get away with it, because their > > > > > > application does all the right things to make it ok, but I don't > > > > > > think you can make a decsion like this for all users based on the > > > > > > request of a single user. > > > > > > > > > > > > It seems like the right thing is for OVS to augment their build time > > > > > > configuration to allow developers to select the ability to use > > > > > > experimental apis at compile time, and then the decision is placed > > > > > > in > > > > > > the hands of end users. > > > > > > > > > > So this is not isolated case right ... it is common from API's to > > > > > graduate from experimental to mature, we _want_ that to happen, we > > > > > _want_ APIs to mature. > > > > > > > > > Sure, I can absolutely agree with that, though I would suggest that the > > > > maturity of the ABI is orthogonal to its labeling as such (more on that > > > > below) > > > > > > > > > I am worried what you are proposing will encourage a behavior whereby > > > > > maintainers to wait until the declaration of the next major ABI > > > > > version > > > > > to make these symbol changes, causing these kinds of changes to queue > > > > > up for that release. > > > > > > > > > I think you're probably right about that, and would make the agrument > > > > that thats perfectly fine (again I'll clarify below) > > > > > > > > > And you would have to ask why? In the case of a reasonably mature > > > > > API, > > > > > there will be no functional or signature change - its mature! So what > > > > > is the harm of providing an alias back to Experimental until the next > > > > > ABI version is declared? > > > > > > > > > From a philosophical standpoint, there is absoluely no harm, and I don't > > > > think anyone would disagree, the harm comes from the details of the > > > > implementation, as you've noted. > > > > > > > > > So while yes, you are 100% right - experimental mean no guarantees. > > > > > But if the API is baked, it is not going to change, so I don't see the > > > > > harm. > > > > > > > > > > We don't want the unnecessary triumph of policy over pragmatism. > > > > > > > > > I would make the converse argument here. While I agree that when an API > > > > is mature, theres no point in calling it experimental anymore, I would > > > > also suggest that, if an API is mature, and not expected to change, > > > > theres no harm in leaving its version tag as experimental for an LTS > > > > release. This is what I was referring to above. Once an application > > > > developer has done the work to integrate an API from DPDK into its > > > > application, that work is done. If the API remains stable, then I > > > > honestly don't know that they care that the version label is > > > > EXPERIMENTAL > > > > versus 20.11 or 20.05 or whatever. They care about the API being stable > > > > more so than its version label. As such, it see
Re: [dpdk-dev] [PATCH] event/octeontx2: remove WFE from dualslot dequeue
On Sat, Feb 15, 2020 at 5:53 PM Gavin Hu wrote: > > Reviewed-by: Gavin Hu Applied to dpdk-next-eventdev/master. Thanks.
Re: [dpdk-dev] [pull-request] next-eventdev 20.02 RC3 or RC4
15/02/2020 09:15, Jerin Jacob Kollanukkaran: > http://dpdk.org/git/next/dpdk-next-eventdev Pulled, thanks
Re: [dpdk-dev] [PATCH] net/octeontx2: fix ptp functionality
On Sat, Feb 15, 2020 at 2:05 PM Harman Kalra wrote:
>
> PTP functionality has been broken after a change in kernel
> where enum npc_kpu_lc_ltype is change to allow adjustment of
> LTYPE_MASK to detect all types of IP headers.
> Syncing the required changes in DPDK to fix the issue.
>
> Fixes: b5dc3140448e ("net/octeontx2: support base PTP")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Harman Kalra
Acked-by: Jerin Jacob
Applied to dpdk-next-net-mrvl/master. Thanks
> ---
> drivers/common/octeontx2/hw/otx2_npc.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/common/octeontx2/hw/otx2_npc.h
> b/drivers/common/octeontx2/hw/otx2_npc.h
> index a0536e0ae..3dfc137a3 100644
> --- a/drivers/common/octeontx2/hw/otx2_npc.h
> +++ b/drivers/common/octeontx2/hw/otx2_npc.h
> @@ -201,7 +201,8 @@ enum npc_kpu_lb_ltype {
> };
>
> enum npc_kpu_lc_ltype {
> - NPC_LT_LC_IP = 1,
> + NPC_LT_LC_PTP = 1,
> + NPC_LT_LC_IP,
> NPC_LT_LC_IP_OPT,
> NPC_LT_LC_IP6,
> NPC_LT_LC_IP6_EXT,
> @@ -209,7 +210,6 @@ enum npc_kpu_lc_ltype {
> NPC_LT_LC_RARP,
> NPC_LT_LC_MPLS,
> NPC_LT_LC_NSH,
> - NPC_LT_LC_PTP,
> NPC_LT_LC_FCOE,
> };
>
> --
> 2.18.0
>
Re: [dpdk-dev] [PATCH] maintainers: update for NFP
11/02/2020 13:23, Heinrich Kuhn: > Jan is no longer with Netronome. Remove him as maintainer for the > Netronome PMD > > Signed-off-by: Heinrich Kuhn Applied
Re: [dpdk-dev] [PATCH] doc: add rte_ring_xxx_elem introduction to rel notes
26/01/2020 18:40, Honnappa Nagarahalli:
> Added introduction of rte_ring_xxx_elem APIs to release notes.
Fixes: cc4b218790f6 ("ring: support configurable element size")
> Signed-off-by: Honnappa Nagarahalli
Applied, thanks
Re: [dpdk-dev] [PATCH v4] net/i40e: relaxed barrier in the tx fastpath
s/relaxed/relax
On 02/12, Gavin Hu wrote:
>To keep ordering of mixed accesses, rte_cio is sufficient.
>The rte_io barrier inside the I40E_PCI_REG_WRITE is overkill.[1]
>
>[1] http://inbox.dpdk.org/dev/CALBAE1M-ezVWCjqCZDBw+MMDEC4O9
>qf0kpn89emdgdajepk...@mail.gmail.com
>
>Fixes: 4861cde46116 ("i40e: new poll mode driver")
>Cc: sta...@dpdk.org
>
>Signed-off-by: Gavin Hu
>---
>V4:
>- add the Fixes tag and CC stable
>V3:
>- optimize the barriers in the fast path only, leave as it is for the
> barriers in the slow path and control path
>- drop the virtio patches from the list as they are in the control path
>- it makes more sense to relax the barrier in the fast path, at the PMD level.
> relaxing the fundamental rte_io_x barriers APIs requires scrutinizations for
> each PMDs which use the barriers directly or indirectly.
>V2:
>- remove virtio_pci_read/write64 APIs definitions, they are not needed and
>generate compiling errors like " error: unused function 'virtio_pci_write64'
>[-Werror,-Wunused-function]"
>- update the reference link to kernel source code
>---
> drivers/net/i40e/i40e_rxtx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
>index fd1ae80da..8c0f7cc67 100644
>--- a/drivers/net/i40e/i40e_rxtx.c
>+++ b/drivers/net/i40e/i40e_rxtx.c
>@@ -1248,7 +1248,8 @@ i40e_xmit_pkts(void *tx_queue, struct rte_mbuf
>**tx_pkts, uint16_t nb_pkts)
> (unsigned) txq->port_id, (unsigned) txq->queue_id,
> (unsigned) tx_id, (unsigned) nb_tx);
>
>- I40E_PCI_REG_WRITE(txq->qtx_tail, tx_id);
>+ rte_cio_wmb();
>+ I40E_PCI_REG_WRITE_RELAXED(txq->qtx_tail, tx_id);
> txq->tx_tail = tx_id;
>
> return nb_tx;
>--
>2.17.1
>
Applied to dpdk-next-net-intel with Jerin's Reviewed-by tag, Thanks.
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix blocking system events
On 01/15, taox@intel.com wrote:
>From: Zhu Tao
>
>IXGBE link status task use rte alarm thread in old implementation.
s/use/uses
>Sometime ixgbe link status task takes up to 9 seconds. This will
>severely affect the rte-alarm-thread-dependent a task in the
>system, like interrupt or hotplug event. So replace with a
s/a/an
>independent thread which has the same thread affinity settings
>as rte interrupt.
>
>Fixes: 0408f47b ("net/ixgbe: fix busy polling while fiber link update")
Should be:
Fixes: 0408f47ba4d6 ("net/ixgbe: fix busy polling while fiber link update")
>Cc: sta...@dpdk.org
>
Applied to dpdk-next-net-intel with Konstantin's ack, Thanks.
Re: [dpdk-dev] [PATCH 2/2] doc: change prog guide to reflect rte_ring_xxx_elem apis
31/01/2020 04:59, Honnappa Nagarahalli: > Changed the rte_ring chapter in programmer's guide to reflect > the addition of rte_ring_xxx_elem APIs. References to pointers > as ring elements is changed to generic term 'objects'. > > Signed-off-by: Honnappa Nagarahalli > Reviewed-by: Gavin Hu Series applied, thanks
Re: [dpdk-dev] [PATCH 0/2] Do proper dependency tracking for doxygen
17/01/2020 12:22, Bruce Richardson: > When building doxygen docs as part of the build, there was no tracking > being done of the files processed, so that doxygen can be re-run if needed. > This patchset adds that tracking support, by generating a gcc-style > ".d" file for the custom targets used in the doc/api build. > > In doing so, we remove the doc directory as a custom target input path > directly, which removes a warning from meson. > > Bruce Richardson (2): > doc/api: generate dependency file for examples doc > doc/api: track header files to rebuild docs on change Applied, thanks
[dpdk-dev] [PATCH v2] devtools: check c99 comment use in checkpatches.sh
C99-style comments are not permitted according to DPDK coding
style guidelines, enable checking for these by checkpatch.pl.
Signed-off-by: Lance Richardson
---
v2:
* Fixed a typo in commit message.
devtools/checkpatches.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index b16bace92..c996a8780 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -33,7 +33,7 @@ VOLATILE,PREFER_PACKED,PREFER_ALIGNED,PREFER_PRINTF,\
PREFER_KERNEL_TYPES,BIT_MACRO,CONST_STRUCT,\
SPLIT_STRING,LONG_LINE_STRING,\
LINE_SPACING,PARENTHESIS_ALIGNMENT,NETWORKING_BLOCK_COMMENT_STYLE,\
-NEW_TYPEDEFS,COMPARISON_TO_NULL"
+NEW_TYPEDEFS,COMPARISON_TO_NULL,C99_COMMENT_TOLERANCE"
options="$options $DPDK_CHECKPATCH_OPTIONS"
print_usage () {
--
2.17.1
[dpdk-dev] [PATCH 20.05] net/af_packet: support default mac address change
Since packet is talking to a network device (probably tap)
it is possible for the device driver to change the hardware address
by making an ioctl to kernel.
Signed-off-by: Stephen Hemminger
---
drivers/net/af_packet/rte_eth_af_packet.c | 28 +++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index f5806bf42c46..ae3c25f2b619 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -468,6 +469,32 @@ eth_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
return 0;
}
+static int
+eth_dev_macaddr_set(struct rte_eth_dev *dev, struct rte_ether_addr *addr)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+ struct ifreq ifr = { };
+ int sockfd = internals->rx_queue[0].sockfd;
+ int ret;
+
+ if (sockfd == -1) {
+ PMD_LOG(ERR, "receive socket not found");
+ return -EINVAL;
+ }
+
+ strlcpy(ifr.ifr_name, internals->if_name, IFNAMSIZ);
+ ifr.ifr_hwaddr.sa_family = ARPHRD_ETHER;
+ memcpy(ifr.ifr_hwaddr.sa_data, addr, sizeof(*addr));
+ ret = ioctl(sockfd, SIOCSIFHWADDR, &ifr);
+
+ if (ret < 0) {
+ PMD_LOG_ERRNO(ERR, "ioctl(SIOCSIFHWADDR) failed");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int
eth_dev_change_flags(char *if_name, uint32_t flags, uint32_t mask)
{
@@ -517,6 +544,7 @@ static const struct eth_dev_ops ops = {
.dev_close = eth_dev_close,
.dev_configure = eth_dev_configure,
.dev_infos_get = eth_dev_info,
+ .mac_addr_set = eth_dev_macaddr_set,
.mtu_set = eth_dev_mtu_set,
.promiscuous_enable = eth_dev_promiscuous_enable,
.promiscuous_disable = eth_dev_promiscuous_disable,
--
2.20.1
Re: [dpdk-dev] [PATCH v1] net/axgbe: add register dump support
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ravi Kumar
>
>-Original Message-
>From: Namburu, Chandu-babu
>Sent: Tuesday, February 11, 2020 3:58 PM
>To: dev@dpdk.org
>Cc: Kumar, Ravi1 ; Somalapuram, Amaranath
>
>Subject: [PATCH v1] net/axgbe: add register dump support
>
>From: Chandu Babu N
>
>Implement "get_reg" eth_dev_ops for axgbe
>
>Signed-off-by: Chandu Babu N
>---
> drivers/net/axgbe/axgbe_common.h | 3 +
> drivers/net/axgbe/axgbe_ethdev.c | 25
> drivers/net/axgbe/axgbe_regs.h | 229 +++
> 3 files changed, 257 insertions(+)
> create mode 100644 drivers/net/axgbe/axgbe_regs.h
>
>diff --git a/drivers/net/axgbe/axgbe_common.h
>b/drivers/net/axgbe/axgbe_common.h
>index fdb037dd5..2ac4d8946 100644
>--- a/drivers/net/axgbe/axgbe_common.h
>+++ b/drivers/net/axgbe/axgbe_common.h
>@@ -289,6 +289,9 @@
> #define MAC_RQC2_INC 4
> #define MAC_RQC2_Q_PER_REG4
>
>+#define MAC_MACAHR(i) (MAC_MACA0HR + ((i) * 8))
>+#define MAC_MACALR(i) (MAC_MACA0LR + ((i) * 8))
>+
> /* MAC register entry bit positions and sizes */
> #define MAC_HWF0R_ADDMACADRSEL_INDEX 18
> #define MAC_HWF0R_ADDMACADRSEL_WIDTH 5
>diff --git a/drivers/net/axgbe/axgbe_ethdev.c
>b/drivers/net/axgbe/axgbe_ethdev.c
>index 7445c544d..00974e737 100644
>--- a/drivers/net/axgbe/axgbe_ethdev.c
>+++ b/drivers/net/axgbe/axgbe_ethdev.c
>@@ -7,6 +7,7 @@
> #include "axgbe_ethdev.h"
> #include "axgbe_common.h"
> #include "axgbe_phy.h"
>+#include "axgbe_regs.h"
>
> static int eth_axgbe_dev_init(struct rte_eth_dev *eth_dev); static int
> eth_axgbe_dev_uninit(struct rte_eth_dev *eth_dev); @@ -21,6 +22,8 @@ static
> int axgbe_dev_allmulticast_enable(struct rte_eth_dev *dev); static int
> axgbe_dev_allmulticast_disable(struct rte_eth_dev *dev); static int
> axgbe_dev_link_update(struct rte_eth_dev *dev,
>int wait_to_complete);
>+static int axgbe_dev_get_regs(struct rte_eth_dev *dev,
>+struct rte_dev_reg_info *regs);
> static int axgbe_dev_stats_get(struct rte_eth_dev *dev,
> struct rte_eth_stats *stats);
> static int axgbe_dev_stats_reset(struct rte_eth_dev *dev); @@ -158,6 +161,7
> @@ static const struct eth_dev_ops axgbe_eth_dev_ops = {
> .allmulticast_enable = axgbe_dev_allmulticast_enable,
> .allmulticast_disable = axgbe_dev_allmulticast_disable,
> .link_update = axgbe_dev_link_update,
>+ .get_reg = axgbe_dev_get_regs,
> .stats_get= axgbe_dev_stats_get,
> .stats_reset = axgbe_dev_stats_reset,
> .xstats_get = axgbe_dev_xstats_get,
>@@ -393,6 +397,27 @@ axgbe_dev_link_update(struct rte_eth_dev *dev,
> return ret;
> }
>
>+static int
>+axgbe_dev_get_regs(struct rte_eth_dev *dev, struct rte_dev_reg_info
>+*regs) {
>+ struct axgbe_port *pdata = dev->data->dev_private;
>+
>+ if (regs->data == NULL) {
>+ regs->length = axgbe_regs_get_count(pdata);
>+ regs->width = sizeof(uint32_t);
>+ return 0;
>+ }
>+
>+ /* Only full register dump is supported */
>+ if (regs->length &&
>+ regs->length != (uint32_t)axgbe_regs_get_count(pdata))
>+ return -ENOTSUP;
>+
>+ regs->version = pdata->pci_dev->id.vendor_id << 16 |
>+ pdata->pci_dev->id.device_id;
>+ axgbe_regs_dump(pdata, regs->data);
>+ return 0;
>+}
> static void axgbe_read_mmc_stats(struct axgbe_port *pdata) {
> struct axgbe_mmc_stats *stats = &pdata->mmc_stats; diff --git
> a/drivers/net/axgbe/axgbe_regs.h b/drivers/net/axgbe/axgbe_regs.h new file
> mode 100644 index 0..c7e032620
>--- /dev/null
>+++ b/drivers/net/axgbe/axgbe_regs.h
>@@ -0,0 +1,229 @@
>+/* SPDX-License-Identifier: BSD-3-Clause
>+ * Copyright(c) 2019 Advanced Micro Devices, Inc. All rights reserved.
>+ */
>+#ifndef RTE_ETH_AXGBE_REGS_H_
>+#define RTE_ETH_AXGBE_REGS_H_
>+
>+#include "axgbe_common.h"
>+
>+static const uint32_t dma_reg_tbl[] = {
>+ DMA_MR, /* DMA Mode */
>+ DMA_SBMR, /* DMA Sys Bus Mode */
>+ DMA_ISR,/* DMA Interrupt Status */
>+ DMA_AXIARCR,/* DMA AXI Tx AR ACE Ctrl */
>+ DMA_AXIAWCR,/* DMA AXI Rx AW ACE Ctrl */
>+ DMA_AXIAWRCR, /* DMA AXI TxRx AWR ACE Ctrl */
>+ DMA_DSR0, /* DMA Debug Status0 */
>+ DMA_DSR1, /* DMA Debug Status1 */
>+ EDMA_TX_CONTROL,/* DMA Tx EDMA Ctrl */
>+ EDMA_RX_CONTROL,/* DMA Rx EDMA Ctrl */ };
>+
>+static const uint32_t dma_txch_reg_tbl[] = {
>+ DMA_CH_CR, /* DMA Channel Ctrl */
>+ DMA_CH_TCR, /* DMA Tx Ctrl */
>+ DMA_CH_TDLR_HI, /* DMA TxDescList HAddr */
>+ DMA_CH_TDLR_LO, /* DMA TxDescList LAddr */
>+ DMA_CH_TDTR_LO, /* DMA TxDescTail LAddr */
>+ DMA_CH_TDRLR, /* DMA TxDescRing Length */
>+ DMA_CH_IER, /* DMA Interrupt Enable */
>+ DMA
Re: [dpdk-dev] [PATCH v1] net/axgbe: add debug logs
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Ravi Kumar
>
>
>-Original Message-
>From: Namburu, Chandu-babu
>Sent: Tuesday, February 11, 2020 1:50 PM
>To: dev@dpdk.org
>Cc: Kumar, Ravi1 ; Somalapuram, Amaranath
>
>Subject: [PATCH v1] net/axgbe: add debug logs
>
>From: Chandu Babu N
>
>Add debug logs in various modules in axgbe
>
>Signed-off-by: Chandu Babu N
>---
> drivers/net/axgbe/axgbe_dev.c | 17 --
> drivers/net/axgbe/axgbe_ethdev.c | 2 ++
> drivers/net/axgbe/axgbe_i2c.c | 10 ++
> drivers/net/axgbe/axgbe_mdio.c | 51 +-
> drivers/net/axgbe/axgbe_phy_impl.c | 43 -
> 5 files changed, 119 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/net/axgbe/axgbe_dev.c b/drivers/net/axgbe/axgbe_dev.c
>index 83089f20d..2e796c0b3 100644
>--- a/drivers/net/axgbe/axgbe_dev.c
>+++ b/drivers/net/axgbe/axgbe_dev.c
>@@ -260,6 +260,9 @@ static int axgbe_enable_tx_flow_control(struct axgbe_port
>*pdata)
> ehfc = 1;
>
> AXGMAC_MTL_IOWRITE_BITS(pdata, i, MTL_Q_RQOMR, EHFC, ehfc);
>+
>+ PMD_DRV_LOG(DEBUG, "flow control %s for RXq%u\n",
>+ ehfc ? "enabled" : "disabled", i);
> }
>
> /* Set MAC flow control */
>@@ -915,6 +918,9 @@ static void axgbe_config_rx_fifo_size(struct axgbe_port
>*pdata)
> /*Calculate and config Flow control threshold*/
> axgbe_calculate_flow_control_threshold(pdata);
> axgbe_config_flow_control_threshold(pdata);
>+
>+ PMD_DRV_LOG(DEBUG, "%d Rx hardware queues, %d byte fifo per queue\n",
>+ pdata->rx_q_count, q_fifo_size);
> }
>
> static void axgbe_config_tx_fifo_size(struct axgbe_port *pdata) @@ -938,6
> +944,9 @@ static void axgbe_config_tx_fifo_size(struct axgbe_port *pdata)
>
> for (i = 0; i < pdata->tx_q_count; i++)
> AXGMAC_MTL_IOWRITE_BITS(pdata, i, MTL_Q_TQOMR, TQS, p_fifo);
>+
>+ PMD_DRV_LOG(DEBUG, "%d Tx hardware queues, %d byte fifo per queue\n",
>+ pdata->tx_q_count, q_fifo_size);
> }
>
> static void axgbe_config_queue_mapping(struct axgbe_port *pdata) @@ -952,12
> +961,16 @@ static void axgbe_config_queue_mapping(struct axgbe_port *pdata)
> qptc_extra = pdata->tx_q_count % pdata->hw_feat.tc_cnt;
>
> for (i = 0, queue = 0; i < pdata->hw_feat.tc_cnt; i++) {
>- for (j = 0; j < qptc; j++)
>+ for (j = 0; j < qptc; j++) {
>+ PMD_DRV_LOG(DEBUG, "TXq%u mapped to TC%u\n", queue, i);
> AXGMAC_MTL_IOWRITE_BITS(pdata, queue, MTL_Q_TQOMR,
> Q2TCMAP, i);
>- if (i < qptc_extra)
>+ }
>+ if (i < qptc_extra) {
>+ PMD_DRV_LOG(DEBUG, "TXq%u mapped to TC%u\n", queue, i);
> AXGMAC_MTL_IOWRITE_BITS(pdata, queue, MTL_Q_TQOMR,
> Q2TCMAP, i);
>+ }
> }
>
> if (pdata->rss_enable) {
>diff --git a/drivers/net/axgbe/axgbe_ethdev.c
>b/drivers/net/axgbe/axgbe_ethdev.c
>index d0b6f091f..7445c544d 100644
>--- a/drivers/net/axgbe/axgbe_ethdev.c
>+++ b/drivers/net/axgbe/axgbe_ethdev.c
>@@ -201,12 +201,14 @@ axgbe_dev_interrupt_handler(void *param)
> pdata->phy_if.an_isr(pdata);
> /*DMA related interrupts*/
> dma_isr = AXGMAC_IOREAD(pdata, DMA_ISR);
>+ PMD_DRV_LOG(DEBUG, "DMA_ISR=%#010x\n", dma_isr);
> if (dma_isr) {
> if (dma_isr & 1) {
> dma_ch_isr =
> AXGMAC_DMA_IOREAD((struct axgbe_rx_queue *)
> pdata->rx_queues[0],
> DMA_CH_SR);
>+ PMD_DRV_LOG(DEBUG, "DMA_CH0_ISR=%#010x\n", dma_ch_isr);
> AXGMAC_DMA_IOWRITE((struct axgbe_rx_queue *)
> pdata->rx_queues[0],
> DMA_CH_SR, dma_ch_isr);
>diff --git a/drivers/net/axgbe/axgbe_i2c.c b/drivers/net/axgbe/axgbe_i2c.c
>index 204ec3679..ab3738a12 100644
>--- a/drivers/net/axgbe/axgbe_i2c.c
>+++ b/drivers/net/axgbe/axgbe_i2c.c
>@@ -162,9 +162,15 @@ static int axgbe_i2c_isr(struct axgbe_port *pdata)
>
> isr = XI2C_IOREAD(pdata, IC_RAW_INTR_STAT);
>
>+ PMD_DRV_LOG(DEBUG, "I2C interrupt received: status=%#010x\n", isr);
>+
> axgbe_i2c_clear_isr_interrupts(pdata, isr);
>
> if (isr & AXGBE_INTR_TX_ABRT) {
>+ PMD_DRV_LOG(DEBUG,
>+ "I2C TX_ABRT received (%#010x) for target %#04x\n",
>+ state->tx_abort_source, state->op->target);
>+
> axgbe_i2c_disable_interrupts(pdata);
>
> state->ret = -EIO;
>@@ -285,6 +291,8 @@ static void axgbe_i2c_stop(struct axgbe_port *pdata)
> if (!pdata->i2c.started)
>
