[dpdk-dev] L2/3 Tx generator example
Hi IIan, maybe you can refer to pkggen(https://github.com/Pktgen/Pktgen-DPDK) 2014-04-01 23:12 GMT+08:00 Ilan Borenshtein : > Hello, > > I've become a member. > I want to ask the following: > > I'm looking for Layer2/3 Tx generator (not forward) example. > > Thanks, > Ilan >
[dpdk-dev] VM does not receive any packets from testpmd using SR-IOV VF PMD
Hi,
After digging into the problem and read through discussion in
http://article.gmane.org/gmane.comp.networking.dpdk.devel/1393/match=vf,
now my DPDK testpmd could receive packet using SRIOV VF in VM.
In my case, the DPDK manual section 9.2 step 10 should not apply. If in
host, DPDK takes over the PF ixgbe driver, then VF in VM does not work
at all (I could run the testpmd but seeing no tx/rx packet). I got "PMD:
Unhandled Msg 0006" after dpdk takes over the PF ixgbe driver.
Another issue I found is that when using Pktgen-DPDK, setting the
destination mac address using "pktgen.dst_mac("all", "0011:2233:4455");"
does not work. The outgoing packet always has dst_mac "::". As
a result, I use "pktgen.set_mac("all", "0011:2233:4455");" and it works
fine.
Regards,
William
On Fri, Mar 28, 2014 at 4:56 PM, William Tu wrote:
> Hi folks,
>
> I have two Intel Xeon servers connected back-to-back using Intel 82599
> NICs (a sender to a receiver). I followed the steps in DPDK manual section
> 9.3 and use single VF direct pass-through to the VM and run testpmd on the
> VF at the receiver. At the sender side, I run Pktgen and program the VF's
> MAC address as destination mac and sends them out to the VM at 50% rate.
>
> After booting the VM, according to the manual step 10, I need to take over
> the physical function by running the testpmd at host side. Then in VM I
> start the testpmd. The testpmd in VM starts ok without any error, and I
> also check the "show port info all". However, while I keep sending packets
> to the VM, the "show port stats all" always reports 0 RX-packet. Actually
> no packet rx/tx at all.
>
> I've check that without running VM, the sender indeed could send packet to
> the receiver server. I'm wondering how to debug this issue and any comments
> are very appreciated.
> btw, one weird thing is that I try to do "set promisc all on", however I
> check the port info and it is always disabled.
>
> Thank you.
>
> Regards,
> William
>
>
[dpdk-dev] [PATCH 3/6] test-pmd: allow command line selection of forwarding mode
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cyril Chemparathy
> Sent: Thursday, April 03, 2014 6:30 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 3/6] test-pmd: allow command line selection of
> forwarding mode
>
> This commit allows testpmd forwarding mode selection through command line
> parameters instead of having to set this up in
> interactive mode.
>
> Signed-off-by: Cyril Chemparathy
> ---
> app/test-pmd/parameters.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c index
> 18b52cc..67081d7 100644
> --- a/app/test-pmd/parameters.c
> +++ b/app/test-pmd/parameters.c
> @@ -158,6 +158,7 @@ usage(char* progname)
> printf(" --disable-rss: disable rss.\n");
> printf(" --port-topology=N: set port topology (N: paired (default) or "
> "chained).\n");
> + printf(" --forward-mode=N: set forwarding mode.\n");
The help text should probably include a list of what the modes are and what
values need to be provided for each one.
[dpdk-dev] [PATCH] mk: add support for gdb debug info generation
Hi Cyril, We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you can use to enable debug, or any other compiler/linker options you need. Wonder, why that is not enough? Thanks Konstantin -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Cyril Chemparathy Sent: Thursday, April 03, 2014 6:31 PM To: dev at dpdk.org Subject: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation It is often useful to build with debug enabled, we add a config (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so. Note: This patch does not include corresponding changes for ICC. The author pleads abject ignorance in this regard, and welcomes recommendations. :-) Signed-off-by: Cyril Chemparathy --- config/defconfig_x86_64-default-linuxapp-gcc | 1 + mk/toolchain/gcc/rte.vars.mk | 5 + 2 files changed, 6 insertions(+) diff --git a/config/defconfig_x86_64-default-linuxapp-gcc b/config/defconfig_x86_64-default-linuxapp-gcc index f11ffbf..3b36efd 100644 --- a/config/defconfig_x86_64-default-linuxapp-gcc +++ b/config/defconfig_x86_64-default-linuxapp-gcc @@ -67,6 +67,7 @@ CONFIG_RTE_ARCH_X86_64=y # CONFIG_RTE_TOOLCHAIN="gcc" CONFIG_RTE_TOOLCHAIN_GCC=y +CONFIG_RTE_TOOLCHAIN_DEBUG=n # # Use intrinsics or assembly code for key routines diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk index 0edb93f..81ed3fa 100644 --- a/mk/toolchain/gcc/rte.vars.mk +++ b/mk/toolchain/gcc/rte.vars.mk @@ -68,6 +68,11 @@ ifeq (,$(findstring -O0,$(EXTRA_CFLAGS))) endif endif +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y) +TOOLCHAIN_CFLAGS += -g -ggdb +TOOLCHAIN_LDFLAGS += -g -ggdb +endif + WERROR_FLAGS := -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes WERROR_FLAGS += -Wmissing-declarations -Wold-style-definition -Wpointer-arith WERROR_FLAGS += -Wcast-align -Wnested-externs -Wcast-qual -- 1.8.3.1
[dpdk-dev] bypass event for reboot
Hi! I have been able to use the below API to set the bypass event on power off and power on * int rte_eth_dev_bypass_event_store (uint8_t port, uint32_t event, uint32_t state) is there a similar way to set the bypass state on "reboot" event ? can anyone please let me know about this. thanks in advance Sharath.
[dpdk-dev] FW: Issues on FDIR and multi-processes
Hi Bruce, thanks for the reply; I'm trying to do what you suggest, in particular I set the value of the lcore_id variable with this instruction: RTE_PER_LCORE(_lcore_id) = temp_lcore_id; where temp_lcore_id is a unique id strictly less then RTE_MAX_LCORE; the instruction is placed just after the "rte_eal_init" call in my main function. I still have the same problem whit the secondary processes. Do you think there could be other issues with the secondary-processes on the some core? Did I do something wrong in the _lcore_id setting? Regards. Mauro > From: bruce.richardson at intel.com > To: mauroannarumma at hotmail.it; dev at dpdk.org > Subject: RE: [dpdk-dev] Issues on FDIR and multi-processes > Date: Wed, 2 Apr 2014 15:33:09 + > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mauro Annarumma > > Sent: Wednesday, April 02, 2014 4:02 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] Issues on FDIR and multi-processes > > > > Hi everyone, > > we are working with Flow DIRector on a multiprocess application. This > > application consists of N secondary processes, > > each one receiving packets directly from its own queue on the NIC. It works > > fine when each secondary process runs on > > a different CPU core; instead, if we try to run two secondary processes on > > the same CPU core, these processes aren't > > able to read from their respectively queue. > > Running two co-operating Intel DPDK processes on the same lcore is not a > supported configuration of Intel DPDK multiprocess. [Please see section 20.3 > of the Intel DPDK Programmer's Guide document, which lists out some > limitations of multi-process support]. Basically, each process in a > multiprocess configuration is equivalent to a thread in a normal application > deployment, so just as having two threads on the same core causes problems > with mempools and other objects which use an "lcore_id" value unique in each > thread to work correctly, so running two processes on the same lcore can > cause exactly the same issues. > If you really do want to use this model and have multiple threads on the same > lcore, at minimum you need to ensure that each thread/process has a unique > lcore_id value <= RTE_MAX_LCORE. > > /Bruce
