* [dpdk-dev] dpdk-2.0.0: crash in ixgbe_recv_scattered_pkts_vec->_recv_raw_pkts_vec->desc_to_olflags_v
@ 2015-06-30 15:49 Gopakumar Choorakkot Edakkunni
2015-06-30 16:08 ` Bruce Richardson
2015-06-30 16:08 ` Thomas Monjalon
0 siblings, 2 replies; 6+ messages in thread
From: Gopakumar Choorakkot Edakkunni @ 2015-06-30 15:49 UTC (permalink / raw)
To: dev
Hi,
I am starting to tryout dpdk-2.0.0 with a simple Rx routine very
similar to the l2fwd example - I am running this on a c3.8xlarge aws
sr-iov enabled vpc instance (inside the vm it uses ixgbevf driver).
Once in every 10 minutes my application crashes in the recieve path.
And whenever I check the crash reason its because it always has three
packets in the burst array (I have provided array size of 32) instead
of the four that it tries to collect in one bunch. And inside
desc_to_olflags_v(), theres the assumption that there are four
packets, and obviously it crashes trying to access the fourth buffer.
With a brief look at the code, I really cant make out how its
guaranteed that we will always have four descriptors fully populated ?
After the first iteration, the loop does break out if (likely(var !=
RTE_IXGBE_DESCS_PER_LOOP)), but how about the very first iteration
where we might not have four ?
Any thoughts will be helpful here, trying to get my app working for
more than 10 minutes :)
#0 0x00000000004c8c58 in desc_to_olflags_v (rx_pkts=0x7f1cb0ff17a0,
descs=<synthetic pointer>)
at /home/gopa/dpdk-2.0.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:173
#1 _recv_raw_pkts_vec (rxq=0x7f1d364fcbc0, rx_pkts=<optimized out>,
nb_pkts=<optimized out>, split_packet=0x7f1cb0ff16d0 "")
at /home/gopa/dpdk-2.0.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:305
#2 0x00000000004c9cea in ixgbe_recv_scattered_pkts_vec
(rx_queue=0x7f1d364fcbc0, rx_pkts=0x7f1cb0ff17a0,
nb_pkts=<optimized out>) at
/home/gopa/dpdk-2.0.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:475
#3 0x00000000006b9bd8 in rte_eth_rx_burst (port_id=0 '\000',
queue_id=0, rx_pkts=0x7f1cb0ff17a0, nb_pkts=32)
at /home/gopa/usr/dpdk/include/rte_ethdev.h:2417
---
(gdb) frame 0
#0 0x00000000004c8c58 in desc_to_olflags_v (rx_pkts=0x7f1cb0ff17a0,
descs=<synthetic pointer>)
at /home/gopa/dpdk-2.0.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:173
173 /home/gopa/dpdk-2.0.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c: No
such file or directory.
(gdb) p rx_pkts[0]
$9 = (struct rte_mbuf *) 0x7f1cf8284640
(gdb) p rx_pkts[1]
$10 = (struct rte_mbuf *) 0x7f1d3991061c
(gdb) p rx_pkts[2]
$11 = (struct rte_mbuf *) 0x7f1d364fc740
(gdb) p rx_pkts[3]
$12 = (struct rte_mbuf *) 0x0
(gdb)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] dpdk-2.0.0: crash in ixgbe_recv_scattered_pkts_vec->_recv_raw_pkts_vec->desc_to_olflags_v
2015-06-30 15:49 [dpdk-dev] dpdk-2.0.0: crash in ixgbe_recv_scattered_pkts_vec->_recv_raw_pkts_vec->desc_to_olflags_v Gopakumar Choorakkot Edakkunni
@ 2015-06-30 16:08 ` Bruce Richardson
2015-06-30 16:08 ` Thomas Monjalon
1 sibling, 0 replies; 6+ messages in thread
From: Bruce Richardson @ 2015-06-30 16:08 UTC (permalink / raw)
To: Gopakumar Choorakkot Edakkunni; +Cc: dev
On Tue, Jun 30, 2015 at 08:49:32AM -0700, Gopakumar Choorakkot Edakkunni wrote:
> Hi,
>
> I am starting to tryout dpdk-2.0.0 with a simple Rx routine very
> similar to the l2fwd example - I am running this on a c3.8xlarge aws
> sr-iov enabled vpc instance (inside the vm it uses ixgbevf driver).
>
> Once in every 10 minutes my application crashes in the recieve path.
> And whenever I check the crash reason its because it always has three
> packets in the burst array (I have provided array size of 32) instead
> of the four that it tries to collect in one bunch. And inside
> desc_to_olflags_v(), theres the assumption that there are four
> packets, and obviously it crashes trying to access the fourth buffer.
>
> With a brief look at the code, I really cant make out how its
> guaranteed that we will always have four descriptors fully populated ?
> After the first iteration, the loop does break out if (likely(var !=
> RTE_IXGBE_DESCS_PER_LOOP)), but how about the very first iteration
> where we might not have four ?
>
> Any thoughts will be helpful here, trying to get my app working for
> more than 10 minutes :)
>
The code is designed to work off the fact that it will always process four
descriptors at a time, and fill in the contents of four mbufs. The main loop
will always do the work to receive four packets, and then subsequently make
a decision as to how many of the four are actually valid packets. If the 4th
descriptor processed has not actually been written back by the NIC, then we
in effect just "throw away" the work we have done for that packet. The mbuf
that was just filled in by the receive, will be filled in again later when
the descriptor has actually been written back. This way we can get linear code
without branching for each packet, at the cost of some additional instructions
for packets that are not yet ready. [And if packets are not yet ready, then
the software is working faster than packets are arriving so we have spare cycles
to spend doing the extra bit of work].
As for the specific problem you are seeing, I'll have to try and reproduce it.
My initial test [with a 10G NIC on the host not a VM - they use the same RX path]
sending in 3 packets at a time, did not show up any issues. Can you perhaps
isolate any further the root cause of the issue. For example, does it only
occur when you get three packets at the receive ring wraps back around to zero?
Regards,
/Bruce
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] dpdk-2.0.0: crash in ixgbe_recv_scattered_pkts_vec->_recv_raw_pkts_vec->desc_to_olflags_v
2015-06-30 15:49 [dpdk-dev] dpdk-2.0.0: crash in ixgbe_recv_scattered_pkts_vec->_recv_raw_pkts_vec->desc_to_olflags_v Gopakumar Choorakkot Edakkunni
2015-06-30 16:08 ` Bruce Richardson
@ 2015-06-30 16:08 ` Thomas Monjalon
2015-06-30 18:28 ` Gopakumar Choorakkot Edakkunni
1 sibling, 1 reply; 6+ messages in thread
From: Thomas Monjalon @ 2015-06-30 16:08 UTC (permalink / raw)
To: Gopakumar Choorakkot Edakkunni; +Cc: dev
2015-06-30 08:49, Gopakumar Choorakkot Edakkunni:
> I am starting to tryout dpdk-2.0.0 with a simple Rx routine very
> similar to the l2fwd example - I am running this on a c3.8xlarge aws
> sr-iov enabled vpc instance (inside the vm it uses ixgbevf driver).
You mean you are using SR-IOV from Amazon, right?
Do you have more hardware details?
> Once in every 10 minutes my application crashes in the recieve path.
> And whenever I check the crash reason its because it always has three
> packets in the burst array (I have provided array size of 32) instead
> of the four that it tries to collect in one bunch. And inside
> desc_to_olflags_v(), theres the assumption that there are four
> packets, and obviously it crashes trying to access the fourth buffer.
Did you try to disable CONFIG_RTE_IXGBE_INC_VECTOR?
> With a brief look at the code, I really cant make out how its
> guaranteed that we will always have four descriptors fully populated ?
> After the first iteration, the loop does break out if (likely(var !=
> RTE_IXGBE_DESCS_PER_LOOP)), but how about the very first iteration
> where we might not have four ?
>
> Any thoughts will be helpful here, trying to get my app working for
> more than 10 minutes :)
Not needed. A DPDK application is fast enough to do the job in 10 minutes ;)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] dpdk-2.0.0: crash in ixgbe_recv_scattered_pkts_vec->_recv_raw_pkts_vec->desc_to_olflags_v
2015-06-30 16:08 ` Thomas Monjalon
@ 2015-06-30 18:28 ` Gopakumar Choorakkot Edakkunni
2015-07-01 0:50 ` Gopakumar Choorakkot Edakkunni
0 siblings, 1 reply; 6+ messages in thread
From: Gopakumar Choorakkot Edakkunni @ 2015-06-30 18:28 UTC (permalink / raw)
To: Thomas Monjalon, bruce.richardson; +Cc: dev
[-- Attachment #1: Type: text/plain, Size: 3166 bytes --]
Hi Thomas, Bruce,
Thanks for the responses. Please find my answers as below.
Thomas>> "You mean you are using SR-IOV from Amazon, right? Do you
have more hardware details?"
That is correct. I am attaching three files cpuinfo.txt lcpci.txt and
portconf.txt (just the port config that I am using, nothing special,
yanked off of l2fwd example). The two 82599 VF interfaces seen in
lspci output are the ones of interest - I use one of them in dpdk
mode.
Thomas>> Did you try to disable CONFIG_RTE_IXGBE_INC_VECTOR?
Thanks for the suggestion, I made that change and was giving it some
time. Now the result of that is not entirely black and white:
previously (in vector mode) my app used to Rx/Tx packets nicely
without any hiccups, but would crash in 10 minutes :). Now with this
suggested change, its been running for a while and doesnt crash, but
the Tx latency and Tx loss is so high (around 10% tx loss) that the
app is not doing a great job - but that might just be something that I
need to adapt to when using non-vector mode ? I will experiment on
that a bit more. So I "think" its fair to say that with the vector
disabled, theres no crash, but I need to chase this latency/loss now.
Thomas>> Not needed. A DPDK application is fast enough to do the job
in 10 minutes ;)
Haha, good one :). Thats where I want to get to eventually, but right
now some distance from it.
Bruce>> Can you perhaps isolate any further the root cause of the
issue. For example, does it only occur when you get three packets at
the receive ring wraps back around to zero?
I will try some more experiments, will read and understand this Rx
code a bit more to be able to answer the qn about whether ring wraps
around when the problem happens etc..
Rgds,
Gopa.
On Tue, Jun 30, 2015 at 9:08 AM, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:
> 2015-06-30 08:49, Gopakumar Choorakkot Edakkunni:
>> I am starting to tryout dpdk-2.0.0 with a simple Rx routine very
>> similar to the l2fwd example - I am running this on a c3.8xlarge aws
>> sr-iov enabled vpc instance (inside the vm it uses ixgbevf driver).
>
> You mean you are using SR-IOV from Amazon, right?
> Do you have more hardware details?
>
>> Once in every 10 minutes my application crashes in the recieve path.
>> And whenever I check the crash reason its because it always has three
>> packets in the burst array (I have provided array size of 32) instead
>> of the four that it tries to collect in one bunch. And inside
>> desc_to_olflags_v(), theres the assumption that there are four
>> packets, and obviously it crashes trying to access the fourth buffer.
>
> Did you try to disable CONFIG_RTE_IXGBE_INC_VECTOR?
>
>> With a brief look at the code, I really cant make out how its
>> guaranteed that we will always have four descriptors fully populated ?
>> After the first iteration, the loop does break out if (likely(var !=
>> RTE_IXGBE_DESCS_PER_LOOP)), but how about the very first iteration
>> where we might not have four ?
>>
>> Any thoughts will be helpful here, trying to get my app working for
>> more than 10 minutes :)
>
> Not needed. A DPDK application is fast enough to do the job in 10 minutes ;)
>
[-- Attachment #2: cpuinfo.txt --]
[-- Type: text/plain, Size: 25561 bytes --]
root@ip-10-0-0-155:/home/ubuntu# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 0
cpu cores : 8
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 1
cpu cores : 8
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 2
cpu cores : 8
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 3
cpu cores : 8
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 4
cpu cores : 8
apicid : 8
initial apicid : 8
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 5
cpu cores : 8
apicid : 10
initial apicid : 10
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 6
cpu cores : 8
apicid : 12
initial apicid : 12
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 7
cpu cores : 8
apicid : 14
initial apicid : 14
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 8
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 0
cpu cores : 8
apicid : 32
initial apicid : 32
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 9
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 1
cpu cores : 8
apicid : 34
initial apicid : 34
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 10
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 2
cpu cores : 8
apicid : 36
initial apicid : 36
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 11
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 3
cpu cores : 8
apicid : 38
initial apicid : 38
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 12
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 4
cpu cores : 8
apicid : 40
initial apicid : 40
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 13
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 5
cpu cores : 8
apicid : 42
initial apicid : 42
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 14
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 6
cpu cores : 8
apicid : 44
initial apicid : 44
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 15
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 7
cpu cores : 8
apicid : 46
initial apicid : 46
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 16
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 0
cpu cores : 8
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 17
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 1
cpu cores : 8
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 18
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 2
cpu cores : 8
apicid : 5
initial apicid : 5
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 19
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 3
cpu cores : 8
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 20
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 4
cpu cores : 8
apicid : 9
initial apicid : 9
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 21
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 5
cpu cores : 8
apicid : 11
initial apicid : 11
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 22
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 6
cpu cores : 8
apicid : 13
initial apicid : 13
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 23
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 0
siblings : 16
core id : 7
cpu cores : 8
apicid : 15
initial apicid : 15
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5586.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 24
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 0
cpu cores : 8
apicid : 33
initial apicid : 33
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 25
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 1
cpu cores : 8
apicid : 35
initial apicid : 35
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 26
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 2
cpu cores : 8
apicid : 37
initial apicid : 37
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 27
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 3
cpu cores : 8
apicid : 39
initial apicid : 39
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 28
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 4
cpu cores : 8
apicid : 41
initial apicid : 41
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 29
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 5
cpu cores : 8
apicid : 43
initial apicid : 43
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 30
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 6
cpu cores : 8
apicid : 45
initial apicid : 45
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 31
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
stepping : 4
microcode : 0x428
cpu MHz : 2793.394
cache size : 25600 KB
physical id : 1
siblings : 16
core id : 7
cpu cores : 8
apicid : 47
initial apicid : 47
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 5656.88
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
root@ip-10-0-0-155:/home/ubuntu#
[-- Attachment #3: lspci.txt --]
[-- Type: text/plain, Size: 704 bytes --]
root@ip-10-0-0-155:/home/ubuntu# lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
00:04.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
00:1f.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
root@ip-10-0-0-155:/home/ubuntu#
[-- Attachment #4: portconf.txt --]
[-- Type: text/plain, Size: 496 bytes --]
struct rte_eth_conf port_conf = {
.rxmode = {
.mq_mode = ETH_MQ_RX_NONE,
.split_hdr_size = 0,
.header_split = 0, /**< Header Split disabled */
.hw_ip_checksum = 0, /**< IP checksum offload disabled */
.hw_vlan_filter = 0, /**< VLAN filtering disabled */
.jumbo_frame = 0, /**< Jumbo Frame Support disabled */
.hw_strip_crc = 1, /**< CRC stripped by hardware */
},
.txmode = {
.mq_mode = ETH_MQ_TX_NONE,
},
};
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] dpdk-2.0.0: crash in ixgbe_recv_scattered_pkts_vec->_recv_raw_pkts_vec->desc_to_olflags_v
2015-06-30 18:28 ` Gopakumar Choorakkot Edakkunni
@ 2015-07-01 0:50 ` Gopakumar Choorakkot Edakkunni
2015-07-01 11:11 ` Bruce Richardson
0 siblings, 1 reply; 6+ messages in thread
From: Gopakumar Choorakkot Edakkunni @ 2015-07-01 0:50 UTC (permalink / raw)
To: Thomas Monjalon, bruce.richardson; +Cc: dev
So update on this. Summary is that its purely my fault, apologies for
prematurely suspecting the wrong areas. Details below
1. So my AWS box had an eth0 interface without DPDK, I enabled dpdk
AND created a KNI interface also AND named the KNI interface to be
eth0
2. So Ubuntu started its dhcpclient on that interface, but my app
doesnt really do anything do read the dhcp (renews) from the KNI and
send it out the physical port and vice versa .. The kni was just
sitting there not doing much of Rx/Tx
3. Now my l2fwd-equivalent code started working fine, after a few
minutes, the dhcp client on ubuntu gave up attempting dhcp renew (eth0
already had an IP) and attempted to take off the IP from eth0
4. At this point the standard KNI examples in dpdk which has callbacks
registered, ended up being invoked - and the examples have a
port_stop() and a port_start() in them - and exactly at this point my
app crashed
So my bad! I just no-oped the callbacks for now and changed AWS eht0
from dhcp to static IP and this are fine now ! My system has been up
for long with no issues.
Thanks again Thomas and Bruce for the quick response and suggestions
Rgds,
Gopa.
On Tue, Jun 30, 2015 at 11:28 AM, Gopakumar Choorakkot Edakkunni
<gopakumar.c.e@gmail.com> wrote:
> Hi Thomas, Bruce,
>
> Thanks for the responses. Please find my answers as below.
>
> Thomas>> "You mean you are using SR-IOV from Amazon, right? Do you
> have more hardware details?"
>
> That is correct. I am attaching three files cpuinfo.txt lcpci.txt and
> portconf.txt (just the port config that I am using, nothing special,
> yanked off of l2fwd example). The two 82599 VF interfaces seen in
> lspci output are the ones of interest - I use one of them in dpdk
> mode.
>
> Thomas>> Did you try to disable CONFIG_RTE_IXGBE_INC_VECTOR?
>
> Thanks for the suggestion, I made that change and was giving it some
> time. Now the result of that is not entirely black and white:
> previously (in vector mode) my app used to Rx/Tx packets nicely
> without any hiccups, but would crash in 10 minutes :). Now with this
> suggested change, its been running for a while and doesnt crash, but
> the Tx latency and Tx loss is so high (around 10% tx loss) that the
> app is not doing a great job - but that might just be something that I
> need to adapt to when using non-vector mode ? I will experiment on
> that a bit more. So I "think" its fair to say that with the vector
> disabled, theres no crash, but I need to chase this latency/loss now.
>
> Thomas>> Not needed. A DPDK application is fast enough to do the job
> in 10 minutes ;)
>
> Haha, good one :). Thats where I want to get to eventually, but right
> now some distance from it.
>
> Bruce>> Can you perhaps isolate any further the root cause of the
> issue. For example, does it only occur when you get three packets at
> the receive ring wraps back around to zero?
>
> I will try some more experiments, will read and understand this Rx
> code a bit more to be able to answer the qn about whether ring wraps
> around when the problem happens etc..
>
> Rgds,
> Gopa.
>
>
> On Tue, Jun 30, 2015 at 9:08 AM, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
>> 2015-06-30 08:49, Gopakumar Choorakkot Edakkunni:
>>> I am starting to tryout dpdk-2.0.0 with a simple Rx routine very
>>> similar to the l2fwd example - I am running this on a c3.8xlarge aws
>>> sr-iov enabled vpc instance (inside the vm it uses ixgbevf driver).
>>
>> You mean you are using SR-IOV from Amazon, right?
>> Do you have more hardware details?
>>
>>> Once in every 10 minutes my application crashes in the recieve path.
>>> And whenever I check the crash reason its because it always has three
>>> packets in the burst array (I have provided array size of 32) instead
>>> of the four that it tries to collect in one bunch. And inside
>>> desc_to_olflags_v(), theres the assumption that there are four
>>> packets, and obviously it crashes trying to access the fourth buffer.
>>
>> Did you try to disable CONFIG_RTE_IXGBE_INC_VECTOR?
>>
>>> With a brief look at the code, I really cant make out how its
>>> guaranteed that we will always have four descriptors fully populated ?
>>> After the first iteration, the loop does break out if (likely(var !=
>>> RTE_IXGBE_DESCS_PER_LOOP)), but how about the very first iteration
>>> where we might not have four ?
>>>
>>> Any thoughts will be helpful here, trying to get my app working for
>>> more than 10 minutes :)
>>
>> Not needed. A DPDK application is fast enough to do the job in 10 minutes ;)
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] dpdk-2.0.0: crash in ixgbe_recv_scattered_pkts_vec->_recv_raw_pkts_vec->desc_to_olflags_v
2015-07-01 0:50 ` Gopakumar Choorakkot Edakkunni
@ 2015-07-01 11:11 ` Bruce Richardson
0 siblings, 0 replies; 6+ messages in thread
From: Bruce Richardson @ 2015-07-01 11:11 UTC (permalink / raw)
To: Gopakumar Choorakkot Edakkunni; +Cc: dev
On Tue, Jun 30, 2015 at 05:50:14PM -0700, Gopakumar Choorakkot Edakkunni wrote:
> So update on this. Summary is that its purely my fault, apologies for
> prematurely suspecting the wrong areas. Details below
>
> 1. So my AWS box had an eth0 interface without DPDK, I enabled dpdk
> AND created a KNI interface also AND named the KNI interface to be
> eth0
>
> 2. So Ubuntu started its dhcpclient on that interface, but my app
> doesnt really do anything do read the dhcp (renews) from the KNI and
> send it out the physical port and vice versa .. The kni was just
> sitting there not doing much of Rx/Tx
>
> 3. Now my l2fwd-equivalent code started working fine, after a few
> minutes, the dhcp client on ubuntu gave up attempting dhcp renew (eth0
> already had an IP) and attempted to take off the IP from eth0
>
> 4. At this point the standard KNI examples in dpdk which has callbacks
> registered, ended up being invoked - and the examples have a
> port_stop() and a port_start() in them - and exactly at this point my
> app crashed
>
> So my bad! I just no-oped the callbacks for now and changed AWS eht0
> from dhcp to static IP and this are fine now ! My system has been up
> for long with no issues.
>
> Thanks again Thomas and Bruce for the quick response and suggestions
>
No problem. Thanks for letting us know that this was resolved.
Regards,
/Bruce
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-07-01 11:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-30 15:49 [dpdk-dev] dpdk-2.0.0: crash in ixgbe_recv_scattered_pkts_vec->_recv_raw_pkts_vec->desc_to_olflags_v Gopakumar Choorakkot Edakkunni
2015-06-30 16:08 ` Bruce Richardson
2015-06-30 16:08 ` Thomas Monjalon
2015-06-30 18:28 ` Gopakumar Choorakkot Edakkunni
2015-07-01 0:50 ` Gopakumar Choorakkot Edakkunni
2015-07-01 11:11 ` Bruce Richardson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).