[dpdk-dev] How to debug packet sends to virtual functions
On Tue, Feb 4, 2014 at 2:40 PM, Burakov, Anatoly wrote: > Hi Mats > > Technically, you can use igb_uio on the host as well (DPDK PMD supports > creating virtual devices since at least release 1.5.0), it's just that you'll > have to set everything up yourself inside your host DPDK application (you > can't use "ip net" to set up VF devices if you're using DPDK drivers). > Unfortunately, I'm not familiar enough with that part of the code to comment > on what exactly you should do to make it work with igb_uio, but I can > certainly ask around if you want. > > I also noticed that you are running KVM with virsh. We always run our VM's by > passing QEMU command line directly, without using virsh, so unfortunately I > cannot be of much help here as I'm not familiar with virsh. Your best bet > would be to get whatever parameters virsh passes to QEMU and modify them to > suit your needs and according to DPDK documentation. Hi Anatoly, I finally got things working. I apparently missed an "ifconfig up" in the guest, before starting dpdk. I'm still confused why this would be needed. Is dpdk unable to do a full initialization of the virtual function from the guest? I'm also curious whether this is how it is intended to work, or am I experiencing a strange type of bug? If not, is it documented that ifconfig is needed in the guest? I thought I've read all documentation thoroughly, but sometimes it is easy to miss the obvious anyway... While I got one instance of DPDK running, I got a problem when starting two instances of DPDK running against different virtual functions. These virtual functions stems from the same physical interfaces. Starting them one or the other works fine. I have to adapt my static arp entries since they have different MAC addresses, but this is only expected. When starting them both however, I receive no packets. If one is running and currently processing packets, it will stop doing so the instance the second instance starts. Anyone knowing what could cause such behavior? Regards Mats Liljegren
[dpdk-dev] How to debug packet sends to virtual functions
Hi Mats > Hi Anatoly, > > I finally got things working. I apparently missed an "ifconfig up" in > the > guest, before starting dpdk. I'm still confused why this would be needed. Is > dpdk unable to do a full initialization of the virtual function from the > guest? > You wouldn't be able to call ifconfig on your VF device if you have bound your guest VF device to igb_uio driver. Have you bound your VF device to igb_uio? Or you have enabled automatic port unbinding (which is disabled by default in recent releases)? > While I got one instance of DPDK running, I got a problem when starting two > instances of DPDK running against different virtual functions. These virtual > functions stems from the same physical interfaces. > > Starting them one or the other works fine. I have to adapt my static arp > entries since they have different MAC addresses, but this is only expected. > When starting them both however, I receive no packets. If one is running > and currently processing packets, it will stop doing so the instance the > second > instance starts. > Are you referring to two different VM's each having a separate VF device, or are you trying to run two primary processes on one VM with different VF devices? Best regards, Anatoly Burakov DPDK SW Engineer -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare
[dpdk-dev] Is it possible to have dpdk running with no dependency on a nic ?
Is this a faq ??? On Wed, Feb 12, 2014 at 1:21 PM, Ymo Lists wrote: > 1) I have two apps that need to communicate on the same machine . Is it > possible to have these two apps communicating via dpdk without referencing > a nic ? > > 2) The apps need to run on an amazon vm. How can you run dpdk on an amazon > vm with only one nic if the above is not possible ? >
[dpdk-dev] Is Flow Director supported on the x540 chipset?
Hi, I'm trying to use Flow Director. Initially I used a X540 chipset and I was not able to make it work; I thought it was a compatibility problem with the controller. Maxime suggested to change some lines in the ixgbe_fdir.c file, I changed these lines but it did not give the expected results; At this point I was sure that the problem was the incompatibility between the DPDK and the X540 chipset therefore I retrived a NIC whit a 82599 chipset and I repeated my attempts, unfortunately I got the some problems. In order to be more clear I explain my attempts: I try to run the test-pmd app with the command-line option "--pkt-filter-mode=perfect", the app doesn't start (the rte_eth_dev_start function return an error) otherwise without the --pkt-filter-mode command-line option the application run normally. This is the command line I use to start the program: frog at frog:~/dpdk-1.5.2r1/app/test-pmd$ sudo ./testpmd -c 0x0f -n 2 -m 512 -- -i --portmask=0x3 --nb-cores=2 --pkt-filter-mode=perfect --rxq=2 --txq=2 and the relative output: ... Interactive-mode selected Configuring Port 0 (socket -1) Fail to start port 0 (ret=-5)* Configuring Port 1 (socket -1) Fail to start port 1 (ret=-5)* Please stop the ports first Done testpmd> *ret=-5 is the result of the rte_eth_dev_start function I guess someone was able to use FDIR, at least in the testpmd application. What am I doing wrong? Best regards > From: thomas.monjalon at 6wind.com > To: fulvio.risso at polito.it > Date: Thu, 6 Feb 2014 17:47:21 +0100 > CC: dev at dpdk.org > Subject: Re: [dpdk-dev] Is Flow Director supported on the x540 chipset? > > Hi Fulvio, > > 17/01/2014 12:24, Maxime Leroy: > > On Thu, Jan 16, 2014, Fulvio Risso wrote: > > > by digging into the DPDK code it seems to me that FDIR is not supported > > > on the x540 chipset, while it is supported on 82599. > [...] > > > Is there any plan to support FDIR to the x540 chipset? > > > [...] > > I think you only need to change few lines in > > lib/librte_pmd_ixgbe/ixgbe_fdir.c: > > > > - if (hw->mac.type != ixgbe_mac_82599EB) > > + if (hw->mac.type != ixgbe_mac_82599EB || hw->mac.type != > > ixgbe_mac_X540) > > > > Let me know if you can test it and please provide a patch if it works. > > Have you tried to patch and test flow director for X540 ? > > thanks > -- > Thomas
[dpdk-dev] Is Flow Director supported on the x540 chipset?
Hi, can you please give a few more details about your setup? What version of the Intel DPDK are you using? I tried using the command you give below on my system with 82599-based NICs and testpmd starts up without any issues. Here's the (clipped for brevity) output that I get: $ sudo ./testpmd -c 0x0f -n 2 -m 512 -- -i --portmask=0x3 --nb-cores=2 --pkt-filter-mode=perfect --rxq=2 --txq=2 EAL: No free hugepages reported in hugepages-2048kB EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 1 on socket 0 ... ... Interactive-mode selected previous number of forwarding ports 4 - changed to number of configured ports 2 Configuring Port 0 (socket 1) Configuring Port 1 (socket 1) Configuring Port 2 (socket 1) Configuring Port 3 (socket 1) Checking link statuses... Port 0 Link Up - speed 1 Mbps - full-duplex Port 1 Link Up - speed 1 Mbps - full-duplex Port 2 Link Up - speed 1 Mbps - full-duplex Port 3 Link Up - speed 1 Mbps - full-duplex Done testpmd> Perhaps you could also try turning on some of the IXGBE debug options in your compile time config e.g. defconfig_x86_64-default-linuxapp-gcc. Setting "CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT" and "CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER" to "y" might provide some useful output. Regards, /Bruce > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mauro > Annarumma > Sent: Thursday, February 13, 2014 9:45 AM > To: dev at dpdk.org > Subject: Re: [dpdk-dev] Is Flow Director supported on the x540 chipset? > > Hi, > I'm trying to use Flow Director. Initially I used a X540 chipset and I was not > able to make it work; I thought it was a compatibility problem with the > controller. Maxime suggested to change some lines in the ixgbe_fdir.c file, I > changed these lines but it > did not give the expected results; >At this point I was sure that the problem was the incompatibility between > the DPDK and the X540 chipset therefore I retrived a NIC whit a 82599 > chipset and I repeated my attempts, unfortunately I got the some > problems. > > In order to be more clear I explain my attempts: > I try to run the test-pmd app with the command-line option > "--pkt-filter-mode=perfect", the app doesn't start (the > rte_eth_dev_start > function return an error) otherwise without the --pkt-filter-mode > command-line option the application run > normally. > > This is the command line I use to start the program: > > frog at frog:~/dpdk-1.5.2r1/app/test-pmd$ > sudo ./testpmd -c 0x0f -n 2 -m 512 -- -i --portmask=0x3 --nb-cores=2 --pkt- > filter-mode=perfect --rxq=2 --txq=2 > > > and the relative output: > > ... > Interactive-mode selected > Configuring Port 0 (socket -1) > Fail to start port 0 (ret=-5)* > Configuring Port 1 (socket -1) > Fail to start port 1 (ret=-5)* > Please stop the ports first > Done > testpmd> > > *ret=-5 is the result of the rte_eth_dev_start function > > I guess someone was able to use FDIR, at least in the testpmd application. > What am I doing wrong? > Best regards > > > From: thomas.monjalon at 6wind.com > > To: fulvio.risso at polito.it > > Date: Thu, 6 Feb 2014 17:47:21 +0100 > > CC: dev at dpdk.org > > Subject: Re: [dpdk-dev] Is Flow Director supported on the x540 chipset? > > > > Hi Fulvio, > > > > 17/01/2014 12:24, Maxime Leroy: > > > On Thu, Jan 16, 2014, Fulvio Risso wrote: > > > > by digging into the DPDK code it seems to me that FDIR is not > supported > > > > on the x540 chipset, while it is supported on 82599. > > [...] > > > > Is there any plan to support FDIR to the x540 chipset? > > > > > [...] > > > I think you only need to change few lines in > > > lib/librte_pmd_ixgbe/ixgbe_fdir.c: > > > > > > - if (hw->mac.type != ixgbe_mac_82599EB) > > > + if (hw->mac.type != ixgbe_mac_82599EB || hw->mac.type != > > > ixgbe_mac_X540) > > > > > > Let me know if you can test it and please provide a patch if it works. > > > > Have you tried to patch and test flow director for X540 ? > > > > thanks > > -- > > Thomas >
[dpdk-dev] condition for calling ixgbe_xmit_cleanup
Hi Jeff:
Thanks for your quick response.
So with current design, tx_free_thresh has different meaning depends on
whether simple flag is set or not. But in many sample applications where
simple flag is not activated, tx_free_thresh is the default value(32)
and capacity of ring is 512. That is why I'm asking this question since
looks like we clean up the ring when using more than 32 descriptors of
total 512.
Thanks
Qing
-Original Message-
From: Shaw, Jeffrey B [mailto:jeffrey.b.s...@intel.com]
Sent: Wednesday, February 12, 2014 6:31 PM
To: Qing Wan; dev at dpdk.org
Subject: RE: condition for calling ixgbe_xmit_cleanup
Hi Qing,
The idea is that we do not want to clean the descriptor ring until we
have used "enough" descriptors.
So (nb_tx_desc -nb_tx_free) tells us how many descriptors we've used.
Once we've used "enough" (i.e. tx_free_thresh) then we will try to clean
the descriptor ring.
If you look at the simpler "tx_xmit_pkts()" (simple is kind of a
misnomer here... it refers to simplicity of features, not simplicity of
implementation), we chose to implement the "nb_tx_free < tx_free_thresh"
variant.
The only real difference is that the semantics of "tx_free_thresh"
change from "free descriptors after this many are used" to "free
descriptors after this many are remaining".
Thanks,
Jeff
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qing Wan
Sent: Wednesday, February 12, 2014 3:50 PM
To: dev at dpdk.org
Subject: [dpdk-dev] condition for calling ixgbe_xmit_cleanup
Hi,
There are following code in function ixgbe_xmit_pkts,
if ((txq->nb_tx_desc - txq->nb_tx_free) > txq->tx_free_thresh) {
ixgbe_xmit_cleanup(txq);
}
My understanding is, nb_tx_desc means total number of descriptors in
ring and nx_tx_free represents how many descriptors are available, so
txq->nb_tx_desc - txq->nb_tx_free means how many we have used. I'm not
quite understand the meaning of this comparison. Why is the condition
not something like "if (txq->nb_tx_free < tx_free_thresh)".
really appreciate if someone could help me on this.
Thanks
Qing
