Hi Ben, Yes, it was really a bug in parsing the flow key from the upcall packet, precisely a misunderstanding of how the data_try_pull and data_pull work.
The log commands were helpful in displaying the source key and packet coming from the kernel. ovs-appctl vlog/list ovs-appctl vlog/set dpif:ANY:DBG It would be nice to have the log related commands in the FAQ. Thanks & Regards Jimson On Tue, Aug 4, 2015 at 9:49 AM, Ben Pfaff <[email protected]> wrote: > On Tue, Aug 04, 2015 at 12:46:32AM +0000, jimson chacko wrote: > > Hi Ben, > > > > Thanks for the quick response. > > > > I am not sure whether the flow matches. But a few observations. > > > > 1. There are two flows seen in ofctl dump-flows output before the > > traffic starts. First one is a default rule with action as "NORMAL" > > (hub mode ?). Second one is the new flow which I added with ofctl > > (output is port 2). > > There is no flow in dpctl output at this stage. > > 2. When traffic is started, dpctl output shows only one entry with > > action 2,3. (traffic is entering via port 1). I can see the new field > > also in the dpctl output with mask as zero. As per my understanding, > > this is an evidence that the flow is matched in ovs-vswitchd. But why > > is the mask value zero and also why is the action set as 2,3 instead > > of 2 alone ? > > The packet counters in dpctl and the counters on the added flow in > > ofctl match. So statistics part seems to be fine. > > 3. I added one more flow with a different value for the new field > > using ofctl. Started traffic with both the previous value and new > > value simultaneously. I still observe that there is only one flow in > > dpctl output with the earlier entry. kernel is not able to distinguish > > the flows and the counters are incremented on the existing flow. There > > is no new flow seen in dpctl output. > > 4. Suppose the switch has only the "NORMAL" rule. I started the > > traffic. The hub mode rule is seen in dpctl. Then a flow is added with > > the new field using ofctl. Observed that the dpctl output is updated > > with the new field value and the mask still is zero. No change in the > > actions part. > > > > I put debug logs just after xlate_actions in the hadle_upcalls > > function. The mask value for other fields are printed along with the > > new field. Mask is as expected for other fields except the new field. > > > > I suspect the miniflow part. What are the changes required in miniflow > > when a new field is introduced in flow ? > > Normally, no changes at all. > > I guess your code has a bug. >
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
