[dpdk-dev] what's mean of q_errors, rte_eth_stats_get
Hi, what's mean of q_errors in struct rte_eth_stats? The sum of q_errors equal to ierrors? when i test dpdk by test_pmd , the value of q_errors always is 0 but ierrors is bigger. in struct rte_eth_stats uint64_t q_errors[RTE_ETHDEV_QUEUE_STAT_CNTRS]; /**< Total number of queue packets received that are dropped. */ uint64_t ierrors; /**< Total number of erroneous received packets. */ thanks, enyong -- Forward statistics for port 0 -- RX-packets:9295620RX-dropped:486347 RX-total: 9781967 TX-packets: 0TX-dropped:16 TX-total:16 Stats reg 0 RX-packets: 127 RX-errors: 0 RX-bytes: 51308 Stats reg 1 RX-packets: 9295620 RX-errors: 0 RX-bytes:3755430480 Stats reg 2 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 3 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 4 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 5 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 6 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 7 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 8 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 9 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 10 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 11 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 12 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 13 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 14 RX-packets: 0 RX-errors: 0 RX-bytes: 0 Stats reg 15 RX-packets: 0 RX-errors: 0 RX-bytes: 0
[dpdk-dev] Using DPDK in a multiprocess environment
As a plan B (or C, or D, etc.) you could also try linking your primary process against those same shared libraries, even if they are unused by it. Hopefully that may have the same effect in the primary as in the secondary processes of adjusting your address space region and allow things to get mapped properly. /Bruce > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Rogers, Gerald > Sent: Tuesday, April 08, 2014 6:00 PM > To: elevran; Shaw, Jeffrey B > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] Using DPDK in a multiprocess environment > > Etai, > > If this doesn?t work, then you will need to change the virtual address range > that > is used by DPDK. By default this is set dynamically, however; with DPDK > 1.6you > can change it to any region in the virtual address space you want. > > The problem you have is what you stated, the secondary process is built with > more shared libraries, which load upon application start, and are occupying > the > region that DPDK allocates in the primary for shared regions. > > In DPDK version 1.6 there is an option to change the base address. It is > --base- > virtaddr > > With this option you can set the base address for where the huge pages are > mapped into the process virtual address space. > > This is all implemented within > $DPDK_DIR/lib/librte_eal/linuxapp/eal/eal_memory.c > > Gerald > > > > > > On 4/8/14, 9:07 AM, "elevran" wrote: > > >Jeff, > > > >Thanks for the quick reply. > > > >I'll see if calling eal_init earlier resolves the problem I'm seeing. > >I'm not sure this will resolve the issue if shared objects are loaded > >before > >main() starts... > > > >I understand the rationale for having the same mbuf addresses across > >processes. And indeed they're mapped just fine (--virt-addr also gives > >some control over the mapping?). > >I was wondering if the same logic applies to the mapping of device PCI > >addresses. Are they shared or passed around between processes in the > >same way? > > > >Thanks again for the quick response, > >Etai > >?? 8 2014 18:54, "Shaw, Jeffrey B" > >???: > > > >> Have you tried calling "rte_eal_init()" closer to the beginning of > >> the program in your secondary process (i.e. the first thing in main())? > >> > >> The same mmap address is required. The reason is simple, if process > >>A thinks the virtual address of an mbuf is 123, and process B thinks > >>the virtual address of the same mbuf is 456, either process may > >>segmentation fault, accessing mbuf memory that is not actually mapped > >>into the processes address space. > >> > >> Jeff > >> > >> -Original Message- > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Etai Lev Ran > >> Sent: Tuesday, April 08, 2014 8:13 AM > >> To: dev at dpdk.org > >> Subject: [dpdk-dev] Using DPDK in a multiprocess environment > >> > >> Hi, > >> > >> > >> > >> I'd like to split DPDK application functionality into a setup > >> (primary) process and business logic (secondary) processes. > >> > >> The secondary processes access the hardware queues directly > >> (exclusive queue per process) and not through software rings. > >> > >> > >> > >> I'm running into an initialization problem: > >> > >> - The primary starts and sets up memory and ports and then > >>goes to > >> sleep waiting for termination signal > >> > >> - Secondary processes fail when probing the PCI bus for devices > >> (required, otherwise I get 0 ports visible in the secondary) > >> > >> > >> > >> The error is directly related to the secondary failing to get the > >> *same* virtual address for mmap'ing the UIO device fd's. > >> > >> The reason is that the secondary processes has considerably more > >> shared objects loaded and some of these are > >> > >> loaded and mapped into addresses which the primary used to map UIO fd's. > >> > >> The pci_map_resource() (linuxapp/eal_pci.c) code explicitly requires > >>that the secondary processes get the same mmap'ed > >> > >> address as given to the primary. > >> > >> > >> > >> 1) Is this behavior (same mmap address) required? > >> > >> 2) If so, is there a workaround to cause PCI areas of UIO devices > >>to > >> be > >> mapped to the same location in arbitrary processes? > >> > >> > >> > >> The samples work just fine since all primary and secondary processes > >>have similar set and load order for .so's > >> > >> > >> > >> Using v1.6 on Ubuntu 12.04 64b, ixgbe devices, 1GB hugepages, ASLR > >> disabled. > >> > >> > >> > >> Thanks, > >> > >> Etai > >> > >> > >> > >>
[dpdk-dev] [PATCH] Revert "timer: get TSC frequency from /proc/cpuinfo"
2014-04-07 13:57, Bruce Richardson: > This reverts commit da6fd0759cbeb5fc14991a79e40105b9f6b99059. > > The use of cpuinfo to determine the frequency of the TSC is not > advisable and leads to incorrect results when power management is > in use. This is because, while the TSC frequency does not change > in modern cpus with constant_tsc support, the frequency of the core, > and hence the frequency of the core reported by cpuinfo *does* change. > > Depending on the current frequency of core 0 when an application is > started, the EAL can get a wildly incorrect value for the TSC freq. > Since frequency is scaled down for power saving, any incorrect value > is likely to be lower than the default, which means that any delay > loops inside the code which rely on the TSC will be shorter than > planned. This can cause issues (reported on the mailing list by a number > of people) where ports are not initialized correctly due to delays being > too short. > > Signed-off-by: Bruce Richardson I agree that using CPU frequency for TSC calibration is wrong with constant_tsc support. The goal was to have a precise calibration but the result is the reverse because of constant TSC. Acked and applied. Thank you Bruce for catching this. -- Thomas
[dpdk-dev] l2fwd not working on PF while working on VF
Dear All I have a setup with Intel 82576 DPDK NIC. For one of the available DPDK ports i have created 8 VFs using igb_uio based on steps presented in programmers guide. Some of them are attached to VM, some maybe used on host After some tests with l2fwd application i found out that it is not working for PF, but works perfectly for any VF (both on host and in VM). I'm still trying to find root cause of this issue but maybe someone encountered such problem Thanks in advance Tomasz Kasowicz Setup: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz running Ubuntu 12.04 LTS pci_unbind.py --status Network devices using IGB_UIO driver :01:00.1 '82576NS Gigabit Network Connection' drv=igb_uio unused=igb :02:11.1 '82576 Virtual Function' drv=igb_uio unused=igbvf Network devices using kernel driver === :00:19.0 '82579LM Gigabit Network Connection' if=eth1 drv=e1000e unused= *Active* :01:00.0 '82576NS Gigabit Network Connection' if=eth0 drv=igb unused=igb_uio *Active* :02:10.1 '82576 Virtual Function' if= drv=pci-stub unused=igbvf,igb_uio :02:10.3 '82576 Virtual Function' if= drv=pci-stub unused=igbvf,igb_uio :02:10.5 '82576 Virtual Function' if= drv=pci-stub unused=igbvf,igb_uio :02:10.7 '82576 Virtual Function' if= drv=pci-stub unused=igbvf,igb_uio :02:11.3 '82576 Virtual Function' if= drv=pci-stub unused=igbvf,igb_uio :02:11.5 '82576 Virtual Function' if= drv=pci-stub unused=igbvf,igb_uio :02:11.7 '82576 Virtual Function' if= drv=pci-stub unused=igbvf,igb_uio :04:00.0 '82574L Gigabit Network Connection' if=eth3 drv=e1000e unused=igb_uio Other network devices = cat /sys/bus/pci/devices/\:01\:00.1/max_vfs 8 ls -alrt /sys/bus/pci/devices/\:01\:00.1/virtfn* lrwxrwxrwx 1 root root 0 Apr 9 12:09 /sys/bus/pci/devices/:01:00.1/virtfn7 -> ../:02:11.7 lrwxrwxrwx 1 root root 0 Apr 9 12:09 /sys/bus/pci/devices/:01:00.1/virtfn6 -> ../:02:11.5 lrwxrwxrwx 1 root root 0 Apr 9 12:09 /sys/bus/pci/devices/:01:00.1/virtfn5 -> ../:02:11.3 lrwxrwxrwx 1 root root 0 Apr 9 12:09 /sys/bus/pci/devices/:01:00.1/virtfn4 -> ../:02:11.1 lrwxrwxrwx 1 root root 0 Apr 9 12:09 /sys/bus/pci/devices/:01:00.1/virtfn3 -> ../:02:10.7 lrwxrwxrwx 1 root root 0 Apr 9 12:09 /sys/bus/pci/devices/:01:00.1/virtfn2 -> ../:02:10.5 lrwxrwxrwx 1 root root 0 Apr 9 12:09 /sys/bus/pci/devices/:01:00.1/virtfn1 -> ../:02:10.3 lrwxrwxrwx 1 root root 0 Apr 9 12:09 /sys/bus/pci/devices/:01:00.1/virtfn0 -> ../:02:10.1
[dpdk-dev] l2fwd not working on PF while working on VF
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz K > Sent: Wednesday, April 09, 2014 3:04 PM > To: dev > Subject: [dpdk-dev] l2fwd not working on PF while working on VF > > Dear All > > I have a setup with Intel 82576 DPDK NIC. > For one of the available DPDK ports i have created 8 VFs using igb_uio based > on > steps presented in programmers guide. Some of them are attached to VM, some > maybe used on host > > After some tests with l2fwd application i found out that it is not working > for PF, > but works perfectly for any VF (both on host and in VM). > How many queues are being allocated to each VF? According to the datasheet, the 82576 NIC has only got 16 RX and TX queues, so if you have 8 VF's with 2 RX and TX queues allocated to each, you may have no remaining queues left for the PF to use on the host.
[dpdk-dev] l2fwd not working on PF while working on VF
Hi Bruce Thanks for the tip. I changed VFs to 6 and now everything works ok on PF. Thank You very much Tomasz Kasowicz 2014-04-09 17:10 GMT+02:00 Richardson, Bruce : > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz K > > Sent: Wednesday, April 09, 2014 3:04 PM > > To: dev > > Subject: [dpdk-dev] l2fwd not working on PF while working on VF > > > > Dear All > > > > I have a setup with Intel 82576 DPDK NIC. > > For one of the available DPDK ports i have created 8 VFs using igb_uio > based on > > steps presented in programmers guide. Some of them are attached to VM, > some > > maybe used on host > > > > After some tests with l2fwd application i found out that it is not > working for PF, > > but works perfectly for any VF (both on host and in VM). > > > How many queues are being allocated to each VF? According to the > datasheet, the 82576 NIC has only got 16 RX and TX queues, so if you have 8 > VF's with 2 RX and TX queues allocated to each, you may have no remaining > queues left for the PF to use on the host. >
[dpdk-dev] [PATCH v3 1/2] ixgbe: release software locked semaphores on initialization
-Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Didier Pallard Sent: Tuesday, April 08, 2014 2:30 PM To: dev at dpdk.org Subject: [dpdk-dev] [PATCH v3 1/2] ixgbe: release software locked semaphores on initialization It may happen that DPDK application gets killed while having acquired locks on the ethernet hardware, causing these locks to be never released. On next restart of the application, DPDK skip those ports because it can not acquire the lock, this may cause some ports (or even complete board if SMBI is locked) to be inaccessible from DPDK application until reboot of the hardware. This patch release locks that are supposed to be locked due to an improper exit of the application. Signed-off-by: Didier Pallard --- Acked-by: Konstantin Ananyev
[dpdk-dev] [PATCH v3 2/2] igb: release software locked semaphores on initialization
-Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Didier Pallard Sent: Tuesday, April 08, 2014 2:30 PM To: dev at dpdk.org Subject: [dpdk-dev] [PATCH v3 2/2] igb: release software locked semaphores on initialization It may happen that DPDK application gets killed while having acquired locks on the ethernet hardware, causing these locks to be never released. On next restart of the application, DPDK skip those ports because it can not acquire the lock, this may cause some ports (or even complete board if SMBI is locked) to be inaccessible from DPDK application until reboot of the hardware. This patch release locks that are supposed to be locked due to an improper exit of the application. Signed-off-by: Didier Pallard --- Acked-by: Konstantin Ananyev
[dpdk-dev] l2fwd not working on PF while working on VF
* Richardson, Bruce (bruce.richardson at intel.com) wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz K
> > Sent: Wednesday, April 09, 2014 3:04 PM
> > To: dev
> > Subject: [dpdk-dev] l2fwd not working on PF while working on VF
> >
> > Dear All
> >
> > I have a setup with Intel 82576 DPDK NIC.
> > For one of the available DPDK ports i have created 8 VFs using igb_uio
> > based on
> > steps presented in programmers guide. Some of them are attached to VM, some
> > maybe used on host
> >
> > After some tests with l2fwd application i found out that it is not working
> > for PF,
> > but works perfectly for any VF (both on host and in VM).
>
> How many queues are being allocated to each VF? According to the datasheet,
> the 82576 NIC has only got 16 RX and TX queues, so if you have 8 VF's with 2
> RX and TX queues allocated to each, you may have no remaining queues left for
> the PF to use on the host.
BTW, Linux driver caps VFs at 7 for this reason (#include ). Any reason not to do this w/ igb_uio...e.g.
thanks,
-chris
---
From: Chris Wright
Subject: [PATCH] igb_uio: cap max VFs at 7 to reserve one for PF
To keep from confusing users, cap max VFs at 7, despite PCI SR-IOV config
space showing a max of 8. This reserves a queue pair for the PF.
Signed-off-by: Chris Wright
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 6db8a4a..096fb01 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -130,6 +130,12 @@ store_max_vfs(struct device *dev, struct device_attribute
*attr,
if (0 != strict_strtoul(buf, 0, &max_vfs))
return -EINVAL;
+ /* reserve a queue pair for PF */
+ if (max_vfs > 7) {
+ dev_warn(&pdev->dev, "Maxixum of 7 VFs per PF, using max\n");
+ max_vfs = 7;
+ }
+
if (0 == max_vfs)
pci_disable_sriov(pdev);
else if (0 == local_pci_num_vf(pdev))
[dpdk-dev] [PATCH v3 1/2] ixgbe: release software locked semaphores on initialization
> It may happen that DPDK application gets killed while having acquired locks > on the ethernet hardware, causing these locks to be never released. On next > restart of the application, DPDK skip those ports because it can not > acquire the lock, this may cause some ports (or even complete board if SMBI > is locked) to be inaccessible from DPDK application until reboot of the > hardware. > > This patch release locks that are supposed to be locked due to an improper > exit of the application. > > Signed-off-by: Didier Pallard > Acked-by: Konstantin Ananyev Applied for version 1.6.0r2. So the decision is to try not modify base driver. But the fix should appear in the base driver one day and we must be careful when rebasing on an updated one. In this case, the fix can be done on both side without being harmful. Thanks for fixing this random failure. -- Thomas
[dpdk-dev] [PATCH v3 2/2] igb: release software locked semaphores on initialization
> It may happen that DPDK application gets killed while having acquired locks > on the ethernet hardware, causing these locks to be never released. On next > restart of the application, DPDK skip those ports because it can not > acquire the lock, this may cause some ports (or even complete board if SMBI > is locked) to be inaccessible from DPDK application until reboot of the > hardware. > > This patch release locks that are supposed to be locked due to an improper > exit of the application. > > Signed-off-by: Didier Pallard > Acked-by: Konstantin Ananyev Applied for version 1.6.0r2. So the decision is to try not modify base driver. But the fix should appear in the base driver one day and we must be careful when rebasing on an updated one. In this case, the fix can be done on both side without being harmful. Thanks for fixing this random failure. -- Thomas
[dpdk-dev] DPDK API/ABI Stability
Hey all- I was going to include this as an addendum to the packaging thread on this list, but I can't seem to find it in my inbox, so forgive me starting a new one. I wanted to broach the subject of ABI/API stability on the list here. Given the recent great efforts to make dpdk packagable by disributions, I think we probably need to discuss API stability in more depth and come up with a plan to implement it. Has anyone started looking into this? If not, it seems to me to be reasonable to start by placing a line in the sand with the functions documented here: http://dpdk.org/doc/api/ It seems to me we can start reviewing the API library by library, enusring only those functions are exported, making sure the data types are appropriate for export, and marking them with a linker script to version them appropriately. Thoughts? Neil
[dpdk-dev] DPDK API/ABI Stability
On Wed, 9 Apr 2014 14:39:52 -0400 Neil Horman wrote: > Hey all- > I was going to include this as an addendum to the packaging thread on > this list, but I can't seem to find it in my inbox, so forgive me starting a > new > one. > > I wanted to broach the subject of ABI/API stability on the list here. > Given the recent great efforts to make dpdk packagable by disributions, I > think > we probably need to discuss API stability in more depth and come up with a > plan > to implement it. Has anyone started looking into this? If not, it seems to > me > to be reasonable to start by placing a line in the sand with the functions > documented here: > > http://dpdk.org/doc/api/ > > It seems to me we can start reviewing the API library by library, enusring > only > those functions are exported, making sure the data types are appropriate for > export, and marking them with a linker script to version them appropriately. To what level? source? binary, internal functions? Some of the API's could be stablized without much impact but others such as the device driver interface is incomplete and freezing it would make live hard.
