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 ;)
>