[dpdk-dev] checking packet drop at NIC
hi all, can anyone please let me know about this ?? Tx, -SB On Thu, Feb 6, 2014 at 11:20 AM, Sharath wrote: > hi Vladimir, > > I would like to know if there are any callback mechanism to detect FIFO > errors in NIC ? > could you please let me know. > > Tx > -SB > > > On Fri, Jan 31, 2014 at 12:56 PM, Sharath gmail.com>wrote: > >> thank you Vladimir. >> >> >> On Fri, Jan 31, 2014 at 12:36 PM, Vladimir Medvedkin < >> medvedkinv at gmail.com> wrote: >> >>> Hi Sharath, >>> >>> In DPDK interrupts are disabled to eliminate the performance overhead. >>> Interrupts used only for link status change. So you can poll >>> rte_eth_stats_get and check struct rte_eth_stats for errors. >>> >>> Regards, >>> Vladimir >>> >>> >>> >>> 2014-01-31 Sharath >>> >>> Hi Daniel & all, can anyone please let me know about this. Tx -SB On Thu, Jan 30, 2014 at 4:50 PM, Sharath >>> >wrote: > hi! > > are there any interrupts which are raised by DPDK, for the fifo errors. > > please let me know, where can I find the details and how to handle such > interrupts ? > > Tx > -SB > > > On Thu, Jan 30, 2014 at 2:30 PM, Sharath < sharathjm.bharadwaj at gmail.com>wrote: > >> Thanks Daniel ! >> Let me check it out . . . >> On Jan 29, 2014 8:54 PM, "Daniel Kaminsky" < >> daniel.kaminsky at infinitelocality.com> wrote: >> >>> Hi Sharath, >>> >>> Try rte_eth_stats_get, I think this should give you what you're looking >>> for. >>> >>> Regards, >>> Daniel >>> >>> >>> On Tue, Jan 28, 2014 at 7:29 AM, Sharath < sharathjm.bharadwaj at gmail.com>wrote: >>> hi ! can someone please tell me whether the DPDK provides any method to handle below a. account the packet drops at NIC level ? is there any interrupt raised by DPDK for the same ? b. to check fifo errors ? c. way to check rx and tx in sync Tx, -SB >>> >>> > >>> >>> >> >
[dpdk-dev] checking packet drop at NIC
The Intel DPDK does not at present support interrupts for dropped packets. Only support for link status change interrupts are supported at this time, but since the basics are there, it is possible with a bit of work to add handling for other interrupts if so needed. Regards, /Bruce > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sharath > Sent: Friday, February 07, 2014 5:44 AM > To: Vladimir Medvedkin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] checking packet drop at NIC > > hi all, > can anyone please let me know about this ?? > > Tx, > -SB > > > On Thu, Feb 6, 2014 at 11:20 AM, Sharath > wrote: > > > hi Vladimir, > > > > I would like to know if there are any callback mechanism to detect > > FIFO errors in NIC ? > > could you please let me know. > > > > Tx > > -SB > > > > > > On Fri, Jan 31, 2014 at 12:56 PM, Sharath > wrote: > > > >> thank you Vladimir. > >> > >> > >> On Fri, Jan 31, 2014 at 12:36 PM, Vladimir Medvedkin < > >> medvedkinv at gmail.com> wrote: > >> > >>> Hi Sharath, > >>> > >>> In DPDK interrupts are disabled to eliminate the performance overhead. > >>> Interrupts used only for link status change. So you can poll > >>> rte_eth_stats_get and check struct rte_eth_stats for errors. > >>> > >>> Regards, > >>> Vladimir > >>> > >>> > >>> > >>> 2014-01-31 Sharath > >>> > >>> Hi Daniel & all, > > can anyone please let me know about this. > > Tx > -SB > > > On Thu, Jan 30, 2014 at 4:50 PM, Sharath > >wrote: > > > hi! > > > > are there any interrupts which are raised by DPDK, for the fifo > errors. > > > > please let me know, where can I find the details and how to > > handle > such > > interrupts ? > > > > Tx > > -SB > > > > > > On Thu, Jan 30, 2014 at 2:30 PM, Sharath < > sharathjm.bharadwaj at gmail.com>wrote: > > > >> Thanks Daniel ! > >> Let me check it out . . . > >> On Jan 29, 2014 8:54 PM, "Daniel Kaminsky" < > >> daniel.kaminsky at infinitelocality.com> wrote: > >> > >>> Hi Sharath, > >>> > >>> Try rte_eth_stats_get, I think this should give you what you're > looking > >>> for. > >>> > >>> Regards, > >>> Daniel > >>> > >>> > >>> On Tue, Jan 28, 2014 at 7:29 AM, Sharath < > sharathjm.bharadwaj at gmail.com>wrote: > >>> > hi ! > > can someone please tell me whether the DPDK provides any > method to handle below > > a. account the packet drops at NIC level ? is there any > interrupt raised by DPDK for the same ? > b. to check fifo errors ? > c. way to check rx and tx in sync > > Tx, > -SB > > >>> > >>> > > > > >>> > >>> > >> > >
[dpdk-dev] [memnic PATCH] pmd: enable compiler optimization
Add -O3 in flags, it was missing in initial Makefile. Signed-off-by: Olivier Matz --- pmd/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pmd/Makefile b/pmd/Makefile index 7f96af1..c22f69f 100644 --- a/pmd/Makefile +++ b/pmd/Makefile @@ -39,7 +39,7 @@ O ?= . CC = $(CROSS)gcc override CPPFLAGS += -Wall -Wextra -Werror -override CFLAGS += -fPIC +override CFLAGS += -fPIC -O3 override LDFLAGS += -shared prefix ?= /usr/local -- 1.8.5.3
[dpdk-dev] [memnic PATCH v2] linux: fix build with kernel 3.3
Remove unused dev_ops functions.
The API of some functions (memnic_vlan_rx_add_vid,
memnic_vlan_rx_kill_vid) changed starting from 3.3 kernel. Instead of
using a #ifdef to handle the compilation on any kernel, we can just
remove these functions as they are not needed.
Signed-off-by: Olivier Matz
---
linux/memnic_net.c | 33 -
1 file changed, 33 deletions(-)
Hi Shimamoto-san,
Here is a new version of the patch, I think we don't need the following
functions so we can just remove them instead of keeping several dummy
functions for different kernel versions.
Let me know if you have any comment.
Regards,
Olivier
diff --git a/linux/memnic_net.c b/linux/memnic_net.c
index 747ae51..9019258 100644
--- a/linux/memnic_net.c
+++ b/linux/memnic_net.c
@@ -235,16 +235,6 @@ drop:
return NETDEV_TX_OK;
}
-static u16 memnic_select_queue(struct net_device *netdev,
- struct sk_buff *skb)
-{
- return 0;
-}
-
-static void memnic_set_rx_mode(struct net_device *netdev)
-{
-}
-
static int memnic_set_mac(struct net_device *netdev, void *p)
{
return 0;
@@ -255,23 +245,6 @@ static int memnic_change_mtu(struct net_device *netdev,
int new_mtu)
return 0;
}
-static void memnic_tx_timeout(struct net_device *netdev)
-{
-}
-
-static void memnic_vlan_rx_add_vid(struct net_device *netdev, unsigned short
vid)
-{
-}
-
-static void memnic_vlan_rx_kill_vid(struct net_device *netdev, unsigned short
vid)
-{
-}
-
-static int memnic_ioctl(struct net_device *netdev, struct ifreq *req, int cmd)
-{
- return 0;
-}
-
static struct net_device_stats *memnic_get_stats(struct net_device *netdev)
{
struct memnic_net *memnic = netdev_priv(netdev);
@@ -283,15 +256,9 @@ static const struct net_device_ops memnic_netdev_ops = {
.ndo_open = memnic_open,
.ndo_stop = memnic_close,
.ndo_start_xmit = memnic_start_xmit,
- .ndo_select_queue = memnic_select_queue,
- .ndo_set_rx_mode= memnic_set_rx_mode,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address= memnic_set_mac,
.ndo_change_mtu = memnic_change_mtu,
- .ndo_tx_timeout = memnic_tx_timeout,
- .ndo_vlan_rx_add_vid= memnic_vlan_rx_add_vid,
- .ndo_vlan_rx_kill_vid = memnic_vlan_rx_kill_vid,
- .ndo_do_ioctl = memnic_ioctl,
.ndo_get_stats = memnic_get_stats,
};
--
1.8.5.3
[dpdk-dev] [PATCH] mk: pass CROSS_COMPILE when compiling kernel modules
Pass CROSS_COMPILE to the kernel build system when compiling kernel modules. Although we export CC etc. the top level kernel Makefile will override the environment. As a result it will end up using wrong tools if cross-compilation is desired but CROSS_COMPILE is not set. Signed-off-by: Aaro Koskinen --- mk/rte.module.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mk/rte.module.mk b/mk/rte.module.mk index b3a630e..5d66d90 100644 --- a/mk/rte.module.mk +++ b/mk/rte.module.mk @@ -77,7 +77,7 @@ build: _postbuild # build module $(MODULE).ko: $(SRCS_LINKS) @if [ ! -f $(notdir Makefile) ]; then ln -nfs $(SRCDIR)/Makefile . ; fi - @$(MAKE) -C $(RTE_KERNELDIR) M=$(CURDIR) O=$(RTE_KERNELDIR) + @$(MAKE) -C $(RTE_KERNELDIR) M=$(CURDIR) O=$(RTE_KERNELDIR) CROSS_COMPILE=$(CROSS) # install module in $(RTE_OUTPUT)/kmod $(RTE_OUTPUT)/kmod/$(MODULE).ko: $(MODULE).ko -- 1.8.5.1
[dpdk-dev] NRMK build break
For those who leave the office before verifying they didn?t break the build, a public flogging! :) /usr/bin/ld: cannot find -lipinfo collect2: error: ld returned 1 exit status make: *** [/home/jeff/Colossus/nrmk/dataplane/P2P/obj/debug/libP2P.so] Error 1 make: *** Waiting for unfinished jobs You marked libipinfo.so as an external dependency. You need to make it a makefile dependency. The fix: (jeff at colossus ~/Colossus/nrmk)$ git diff dataplane/P2P/Rules.mk diff --git a/nrmk/dataplane/P2P/Rules.mk b/nrmk/dataplane/P2P/Rules.mk index 2ecc396..093b7ac 100644 --- a/nrmk/dataplane/P2P/Rules.mk +++ b/nrmk/dataplane/P2P/Rules.mk @@ -34,6 +34,7 @@ libP2P.so_DEPS := \ P2PConfig.o \ $(TARGETS_$(TOP)/lib/json) \ $(TARGETS_$(TOP)/lib/notes) \ +$(TARGETS_$(TOP)/lib/ipinfo) LIBDIRS_$(d) = $(TOP)/../lib @@ -41,5 +42,4 @@ libP2P.so_LIBS = \ -lcolossuscommon \ -lcolossuscommand \ -lcolossustrace \ --lcolossusutilities \ --lipinfo +-lcolossusutilities Pushing the fix. Thanks for moving all your algorithms into NRMK! :) Jeff
[dpdk-dev] ASN.1 codec
For those who are interested, I?ve pushed an ASN.1 codec API sufficient for Kerberos parsing to nrmk/include/codec/asn.1. The unit-test is in nrmk/lib/codec/asn.1/test if you want to see how it can be used. I?ll be working on the Kerberos 5 codec next leveraging the BER/DER APIs, so be patient with me. :) Jeff
[dpdk-dev] Not Receiving Multicast packets on SR-IOV VF ports
On a guest VM, I can be receive multicast packets on SR-IOV VF ports. Is
there anyway to enable the VF ports to receive multicast packets ?
However, I could receive multicast packets on non-SR-IOV virtual interface
ports via bridge or OVS on the guest VM after I call this routine
ixgbe_dev_allmulticast_enable() in ixgbe_ethdev.c to enable it.
static struct eth_dev_ops ixgbe_eth_dev_ops = {
.allmulticast_enable =
ixgbe_dev_allmulticast_enable,
}
I do not see the corresponding entry in
static struct eth_dev_ops ixgbevf_eth_dev_ops = {
};
which is used for VF ports.
Is there any other way to make it work ? Anyone has any way to make it work
?
Thanks
James
