[ovs-discuss] mf_value and mf_subvalue size restrictions

[Madhu Challa]

This test was failing because of an assumption in the code on its size.

diff --git a/lib/learn.c b/lib/learn.c
index e93015c..aa4fc45 100644
--- a/lib/learn.c
+++ b/lib/learn.c
@@ -209,7 +209,7 @@ learn_parse_load_immediate(const char *s, struct
ofpact_lear
         }
         s = arrow;
     } else {
-        imm.be64[1] = htonll(strtoull(s, (char **) &s, 0));
+        imm.be64[31] = htonll(strtoull(s, (char **) &s, 0));
     }

I am going over the other failures, I feel it may be something similar.

If you think its a good idea, we can make these dependent on the size of
imm / mf_value rather than a hard coded value. I will be happy to provide a
patch after I debug the remaining failures.


Thanks.

On Wed, Nov 5, 2014 at 10:03 AM, Madhu Challa <challa at noironetworks.com>
wrote:

> Thanks Ben. I will debug and get back to you. I will check with Jesse in
> the upcoming ovs conference if he has other thoughts on implementing this.
>
> Thanks.
>
> On Wed, Nov 5, 2014 at 8:17 AM, Ben Pfaff <blp at nicira.com> wrote:
>
>> On Tue, Nov 04, 2014 at 03:10:59PM -0800, Madhu Challa wrote:
>> > I was playing increasing the size of these structures to be able to read
>> > Geneve metadata. Currently they are limited to 16 bytes. I noticed that
>> > some of the test cases fail when I do this. I guess I can read the oxms
>> > directly without using these structures. But figured its less error
>> prone
>> > if done this way.
>>
>> If we these fields to appear raw in OXMs (I think that Jesse is also
>> thinking about to handle Geneve, and I don't know his thoughts on how to
>> do it) then expanding these structures is probably the right way to do
>> it.
>>
>> Have you investigated why the expansions cause failures?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20141105/fecf7b09/attachment-0002.html>