[dpdk-dev] intel x540-at2
I haven't added it yet, because as of the moment I do not have an access to the built DPDK library I was using. I was just linking it with my DPDK application. I tried to debug it with GDB and disassembled it, the invalid instruction was "vzeroupper" which occurs at rte_eal_init, somewhere when initializing pthreads. Ok, I'll to debug more and get more information. Thanks again, Pepe On Fri, Jan 3, 2014 at 6:26 PM, Thomas Monjalon wrote: > 03/01/2014 11:09, Jose Gavine Cueto : > > I am running a DPDK application in a guest VM which uses one VF. This VM > > runs on top of the host that has an x540-at2 NIC and uses the ixgbe > driver. > > The issue was that every time I run the DPDK application in the VM it > > errors an invalid instruction and stops there. > > First, have you added x540-at2 in ixgbe_type.h, ixgbe_api.c and > rte_pci_dev_ids.h ? > What is the invalid instruction ? Have you tried to debug it ? > > I don't know this NIC so I'm afraid you should debug it by yourself. > > Please, keep us informed if you make it working. > -- > Thomas > -- To stop learning is like to stop loving.
[dpdk-dev] intel x540-at2
Hi Thomas, I thought I was clear enough, sorry for the confusion. I am running a DPDK application in a guest VM which uses one VF. This VM runs on top of the host that has an x540-at2 NIC and uses the ixgbe driver. The issue was that every time I run the DPDK application in the VM it errors an invalid instruction and stops there. I've come into a conclusion that NIC x540-at2 isn't fully supported by DPDK because i can't find a MACRO for it in rte_pci_dev_ids.h. Consequently, I came into a suspicion that this is somewhat causing the DPDK application that runs in the VM to fail, for the reason that the VF in the VM may be trying to perform some capabilities in the PF (x540-at2) that is not available. Cheers, Pepe On Fri, Jan 3, 2014 at 5:56 PM, Thomas Monjalon wrote: > 03/01/2014 10:16, Jose Gavine Cueto : > > Thanks again. So there is a possibility that vf will fail with DPDK due > to > > not fully supported pf. Please correct me if I'm wrong. > > Please Jose, better describe your use case in order to have the right > answer. > > The standard SR-IOV use case is to use a recent ixgbe driver from > kernel.org > or from sourceforge.net for the PF on the host. Then use ixgbevf from > DPDK in > the guest. > It should work. > It is documented in chapter 9 (IXGBE/IGB Virtual Function Driver) of the > programmer's guide: > http://dpdk.org/doc > > -- > Thomas > -- To stop learning is like to stop loving.
[dpdk-dev] intel x540-at2
Thanks again. So there is a possibility that vf will fail with DPDK due to not fully supported pf. Please correct me if I'm wrong. Cheers, Pepe On Fri, Jan 3, 2014 at 5:09 PM, Jose Gavine Cueto wrote: > Sorry I accidentally excluded the list. I've pasted the replies: > > > > --- > I see thanks. > > I'm actually running my DPDK application on a guest OS but I'm always > getting an invalid instruction error. I was thinking that this was due to > ixgbevf driver in guest that commands the host driver which is not-fully > supported by DPDK, and consequently ran an invalid instruction. This > brings me back to the questions: > > Are SR-IOV virtual function drivers supported by DPDK PMD (I guess yes) ? > If yes, does the physical function (host) driver affects the DPDK > application in any way especially if it isn't fully supported yet by DPDK? > > I've tried looking at incompatibility issues with respect to compiler and > processor archs. but it seems OK to me. > > Thanks, > Pepe > > > > > SR-IOV is supported. There are dependencies with PF driver which handle NIC > configuration. VF/PF communication is done via mailbox. > > Please use the list. > > > Thomas > > > > On Thu, Jan 2, 2014 at 10:24 PM, Thomas Monjalon < > thomas.monjalon at 6wind.com> wrote: > >> 23/12/2013 10:18, Jose Gavine Cueto : >> > I can't find a MACRO for this nic in rte_pci_dev_ids.h, does this mean >> this >> > isn't supported as of this moment ? >> >> Yes >> But probably that >> hw->mac.type = ixgbe_mac_X540 >> apply also to x540-at2. >> >> Please to try to add it and send the patch if it works. >> -- >> Thomas >> > > > > -- > To stop learning is like to stop loving. > -- To stop learning is like to stop loving.
[dpdk-dev] intel x540-at2
Sorry I accidentally excluded the list. I've pasted the replies: --- I see thanks. I'm actually running my DPDK application on a guest OS but I'm always getting an invalid instruction error. I was thinking that this was due to ixgbevf driver in guest that commands the host driver which is not-fully supported by DPDK, and consequently ran an invalid instruction. This brings me back to the questions: Are SR-IOV virtual function drivers supported by DPDK PMD (I guess yes) ? If yes, does the physical function (host) driver affects the DPDK application in any way especially if it isn't fully supported yet by DPDK? I've tried looking at incompatibility issues with respect to compiler and processor archs. but it seems OK to me. Thanks, Pepe SR-IOV is supported. There are dependencies with PF driver which handle NIC configuration. VF/PF communication is done via mailbox. Please use the list. Thomas On Thu, Jan 2, 2014 at 10:24 PM, Thomas Monjalon wrote: > 23/12/2013 10:18, Jose Gavine Cueto : > > I can't find a MACRO for this nic in rte_pci_dev_ids.h, does this mean > this > > isn't supported as of this moment ? > > Yes > But probably that > hw->mac.type = ixgbe_mac_X540 > apply also to x540-at2. > > Please to try to add it and send the patch if it works. > -- > Thomas > -- To stop learning is like to stop loving.
[dpdk-dev] intel x540-at2
03/01/2014 13:43, Venkatesan, Venky : > "Jose Gavine Cueto" wrote: > > I tried to debug it with GDB and disassembled it, the invalid instruction > > was "vzeroupper" which occurs at rte_eal_init, somewhere when initializing > > pthreads. > Was the DPDK library compiled on a different machine and the used in the VM? > It looks like it has been compiled for native AVX (hence the vzeroupper). > Could you dump cpuinfo in the VM and see what instruction set the VM > supports? If you are using qemu, the instruction set of the host CPU is used thanks to -cpu host -- Thomas
[dpdk-dev] Comments regarding Flow Director support in PMD IXGBE
Hi, We would like your opinions on the following observations, regarding the 82599 Flow Director support. Issue #1: Our reading of the 82599 data sheet leads us to believe that Flow Director can simultaneously handle *both* IPv4 and IPv6 filters, with separate filter rules, of course. Thus, at the bottom of ixgbe_fdir.c:fdir_set_input_mask_82599( ), we could remove the "if (!input_mask->set_ipv6_mask)" / "else" around the setting of FDIRSIP4M, FDIRDIP4M, and FDIRIP6M. (This would also eliminate the need for the set_ipv6_masks flag itself.) We performed limited testing on this change. We have successfully added both IPv4 and IPv6 signature filters, but so far have only exercised them with IPv4 traffic. One would think that the designers of this chip feature envisioned users filtering mixed traffic (both IPv4 and IPv6). Issue #2: Apparently, API rte_eth_dev_fdir_set_masks( ) expects IPv4 address and port masks in host-byte-order (little-endian), while rte_eth_dev_fdir_add_signature_filter( ) expects IPv4 addresses and ports in network-byte-order (big-endian). (Contrast the writing into IXGBE_FDIRSIP4M in ixgbe_fdir.c: fdir_set_input_mask_82599( ), versus ixgbe/ixgbe_82599.c: ixgbe_fdir_set_input_mask_82599( ). The former includes an extra IXGBE_NTOHL( ) on the mask's complement.) Not knowing this made it a bit tricky to get signature filters working properly. Perhaps it is too late to change the byte-ordering in the (set masks) API? Whether we change it or not, we probably should at least document these details, to avoid confusion. -- Regards, Robert
[dpdk-dev] g++: undefined reference to
Hey Stefan,
Thanks a lot for your answer. I followed your instructions, and have
following problem.
Also I'd like to mention that on my system:
echo $RTE_SDK
/home/hamid/dpdk/dpdk-1.5.1r1
and
echo $RTE_TARGET
x86_64-default-linuxapp-gcc
I get following error now:
/home/hamid/dpdk/dpdk-1.5.1r1/x86_64-default-linuxapp-gcc/lib/librte_eal.a(eal_timer.o):
In function `rte_eal_timer_init':
eal_timer.c:(.text+0x42c): undefined reference to `clock_gettime'
eal_timer.c:(.text+0x468): undefined reference to `clock_gettime'
/home/hamid/dpdk/dpdk-1.5.1r1/x86_64-default-linuxapp-gcc/lib/librte_eal.a(eal_common_nonpci_devs.o):(.data+0x8):
undefined reference to `rte_pmd_ring_init'
collect2: ld returned 1 exit status
make: *** [all] Error 1
my sample.cpp is like this:
#include
#include
extern "C"{
#include
#include
}
#include
class Runner
{
public:
Runner(){};
void run(int argc, char** argv)
{
std::cout << std::string("Calling rte_eal_init") << std::endl;
rte_eal_init(argc, argv);
std::cout << std::string("Called rte_eal_init - done
now!") << std::endl;
};
};
int main(int argc, char** argv)
{
Runner* runner = new Runner();
runner->run(argc, argv);
delete runner;
exit(0);
}
and my Makefile is like this:
all:
g++ -m64 -pthread -march=native -DRTE_MACHINE_CPUFLAG_SSE
-DRTE_MACHINE_CPUFLAG_SSE2 -DRTE_MACHINE_CPUFLAG_SSSE3
-DRTE_COMPILE_TIME_CPUFLAGS=RTE_CPUFLAG_SSE,RTE_CPUFLAG_SSE2,RTE_CPUFLAG_SSSE3
-I/home/hamid/dpdk/dpdk-1.5.1r1/examples/sample/build/include
-I/home/hamid/dpdk/dpdk-1.5.1r1/x86_64-default-linuxapp-gcc/include
-include
/home/hamid/dpdk/dpdk-1.5.1r1/x86_64-default-linuxapp-gcc/include/rte_config.h
-O3 -W -Wall -Werror -Wmissing-declarations -Wpointer-arith
-Wcast-align -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef
-Wwrite-strings -Wl,-melf_x86_64 -Wl,-export-dynamic sample.cpp -o
sample -Wl,-L/home/hamid/dpdk/dpdk-1.5.1r1/examples/sample/build/lib
-Wl,-L/home/hamid/dpdk/dpdk-1.5.1r1/x86_64-default-linuxapp-gcc/lib
-Wl,-L/home/hamid/dpdk/dpdk-1.5.1r1/x86_64-default-linuxapp-gcc/lib
-Wl,-lrte_kni -Wl,-lrte_pmd_e1000 -Wl,-lrte_pmd_ixgbe -Wl,-lrte_mbuf
-Wl,-lrte_cmdline -Wl,-lrte_timer -Wl,-lrte_hash -Wl,-lrte_lpm
-Wl,--start-group -Wl,-lethdev -Wl,-lrte_malloc -Wl,-lrte_mempool
-Wl,-lrte_ring -Wl,-lrte_eal -Wl,-ldl -Wl,--end-group
Your advice is much appreciated.
Thanks in advance.
--Hamid
On 1/3/14, Stefan Baranoff wrote:
> Hamid,
>
> I apologize for the earlier slight misdirection; I was on my phone and
> trying to respond from memory. The actual answer is really to use
> -lrte_static_library_name and not referencing the .o files. Sorry!!!
>
> To get this I ran 'make -n' on the 'Hello World' example app (careful,
> there's the gcc command and then another "&& echo " with the command again
> in there when you run make -n and you really only need the real gcc call,
> not the echo). Below is a sample g++ command that works for me just running
> against a quick C++ files that does an 'rte_eal_init()' so you may need to
> extend it to handle more complex cases.
>
> Note I've stripped out a few pieces that may actually matter and left in
> some don't but work for the moment for this (very) simple case. I don't
> claim to be a GCC guru so we may encounter random failures down the road
> with our approach and are ready to accept that risk until we can get
> someone to review the effect of the removed options. Please take the
> following commands with a grain of salt. The primary omissions are the
> -Wl,-Map and --cref along with stripping out a few warnings
> (-Wstrict-prototypes, -Wmissing-prototypes,
> -Wold-style-definition, -Wnested-externs).
>
> Please note that near the end but before the -Wl,-L options there is the
> reference to my main file "sample.cpp" and the '-o sample' option for my
> file 'sample.cpp' that you would replace - this could be broken out better
> and I'm sure the default Makefile syntax could be extended to support c++
> but I'll leave that to someone else who is better with Make/GCC to
> implement properly.
>
> all:
> g++ -m64 -pthread -march=native -DRTE_MACHINE_CPUFLAG_SSE
> -DRTE_MACHINE_CPUFLAG_SSE2 -DRTE_MACHINE_CPUFLAG_SSSE3
> -DRTE_COMPILE_TIME_CPUFLAGS=RTE_CPUFLAG_SSE,RTE_CPUFLAG_SSE2,RTE_CPUFLAG_SSSE3
> -I/data/home/sbaranoff/DPDKPlayground/dpdk-1.3.1r2/examples/helloworld/build/include
> -I/home/sbaranoff/DPDKPlayground/dpdk-1.3.1r2//x86_64-default-linuxapp-gcc/include
> -include
> /home/sbaranoff/DPDKPlayground/dpdk-1.3.1r2//x86_64-default-linuxapp-gcc/include/rte_config.h
> -O3 -W -Wall -Werror -Wmissing-declarations -Wpointer-arith -Wcast-align
> -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef -Wwrite-strings
> -Wl,-melf_x86_64 -Wl,-exp
[dpdk-dev] intel x540-at2
Pepe , Was the DPDK library compiled on a different machine and the used in the VM? It looks like it has been compiled for native AVX (hence the vzeroupper). Could you dump cpuinfo in the VM and see what instruction set the VM supports? -Venky Sent from my iPhone > On Jan 3, 2014, at 2:32 AM, "Jose Gavine Cueto" wrote: > > I haven't added it yet, because as of the moment I do not have an access to > the built DPDK library I was using. I was just linking it with my DPDK > application. > > I tried to debug it with GDB and disassembled it, the invalid instruction > was "vzeroupper" which occurs at rte_eal_init, somewhere when initializing > pthreads. > > Ok, I'll to debug more and get more information. > > Thanks again, > Pepe > > > On Fri, Jan 3, 2014 at 6:26 PM, Thomas Monjalon > wrote: > >> 03/01/2014 11:09, Jose Gavine Cueto : >>> I am running a DPDK application in a guest VM which uses one VF. This VM >>> runs on top of the host that has an x540-at2 NIC and uses the ixgbe >> driver. >>> The issue was that every time I run the DPDK application in the VM it >>> errors an invalid instruction and stops there. >> >> First, have you added x540-at2 in ixgbe_type.h, ixgbe_api.c and >> rte_pci_dev_ids.h ? >> What is the invalid instruction ? Have you tried to debug it ? >> >> I don't know this NIC so I'm afraid you should debug it by yourself. >> >> Please, keep us informed if you make it working. >> -- >> Thomas > > > > -- > To stop learning is like to stop loving.
[dpdk-dev] g++: undefined reference to
Hello, 03/01/2014 11:48, Hamid Ramazani : > eal_timer.c:(.text+0x42c): undefined reference to `clock_gettime'
[dpdk-dev] intel x540-at2
03/01/2014 11:09, Jose Gavine Cueto : > I am running a DPDK application in a guest VM which uses one VF. This VM > runs on top of the host that has an x540-at2 NIC and uses the ixgbe driver. > The issue was that every time I run the DPDK application in the VM it > errors an invalid instruction and stops there. First, have you added x540-at2 in ixgbe_type.h, ixgbe_api.c and rte_pci_dev_ids.h ? What is the invalid instruction ? Have you tried to debug it ? I don't know this NIC so I'm afraid you should debug it by yourself. Please, keep us informed if you make it working. -- Thomas
[dpdk-dev] intel x540-at2
03/01/2014 10:16, Jose Gavine Cueto : > Thanks again. So there is a possibility that vf will fail with DPDK due to > not fully supported pf. Please correct me if I'm wrong. Please Jose, better describe your use case in order to have the right answer. The standard SR-IOV use case is to use a recent ixgbe driver from kernel.org or from sourceforge.net for the PF on the host. Then use ixgbevf from DPDK in the guest. It should work. It is documented in chapter 9 (IXGBE/IGB Virtual Function Driver) of the programmer's guide: http://dpdk.org/doc -- Thomas
[dpdk-dev] Any sample on VMDq?
Dear all, I would like to use VMDq to select traffic based on "arbitrary" parameters (such as IP addresses) and send it directly to a specific virtual machine. However, this apparently doesn't work or (more likely) I'm making some mistake in the code. Is there anybody that succeeded in doing that? Any sample I can use to see where I am wrong? Thank you very much for your support, fulvio
