Wrapping my attribute in #ifndef __KERNEL__ did the trick! Thanks Ben and
Daniele.
On Wed, Apr 27, 2016 at 9:50 PM, Daniele Di Proietto wrote:
> Short term solution:
>
> Yes, returning "ODP_FIT_TOO_LITTLE" from check_expectations() isn't enough
> to prevent a flow from being installed in the ker
Short term solution:
Yes, returning "ODP_FIT_TOO_LITTLE" from check_expectations() isn't enough to
prevent a flow from being installed in the kernel datapath. OVS userspace,
since the introduction of megaflows, handles compatibility with older kernels
in a different way: the kernel will refuse
I also found a discussion here referring to the same issue, however I am
not sure if it was solved or not ?
https://patchwork.ozlabs.org/patch/555337/
"However, slowpathing ODP_FIT_TOO_LITTLE flow keys needs to be added in
the case where the fields not understood by the datapath are used in
I'm not aware of bugs here, but there could easily be something new,
since this code path isn't exercised very much lately.
Daniele, did you find anything out?
On Wed, Apr 27, 2016 at 10:13:58AM +0300, Enas Ahmad wrote:
> I also found a discussion here referring to the same issue, however I am
>
According to Open vSwitch datapath developer documentation:
https://www.kernel.org/doc/Documentation/networking/openvswitch.txt
"If the userspace flow key includes more fields than the
kernel's, for example if userspace decoded an IPv6 header but
the kernel stopped at the Etherne
I am posting here so if someone else is trying to add a new field to ovs
maybe this can help and save their time.
After debugging I solved my issue by adding the following to nx_put_raw()
in nx-match.c:
if( match->wc.masks.iot_addr){
nxm_put_32m(b, MFF_IOT_ADDR, oxm,
htonl(flow->iot_addr),
Thanks, I've sent out a patch for the FAQ.
On Tue, Mar 22, 2016 at 11:09:54AM +0300, Enas Ahmad wrote:
> I am posting here so if someone else is trying to add a new field to ovs
> maybe this can help and save their time.
> After debugging I solved my issue by adding the following to nx_put_raw()
>
I'm always frankly puzzled by this kind of message that says "I made
some changes to OVS and they didn't work." The answer is that you need
to debug your changes.
On Thu, Mar 17, 2016 at 06:17:10PM +0300, Enas Ahmad wrote:
> Hi,
> I am still having a problem in successfully defining a new field.
Hi,
I am still having a problem in successfully defining a new field. My field
name is iot_addr. I define it in the meta-flow.h file as the following:
/* "iot_addr".
*
* IoT address
*
* Type: be32.
* Maskable: bitwise.
* Formatting: decimal.
* Prerequisites: UDP.
Thanks Ben for the useful answer, following these directions I was able to
add a new field and was able to successfully create a table entry
specifying a value for that filed.
However, now I need to verify the packet extraction process done in
miniflow_extract(). My question is: how can I debug th
On Sun, Mar 13, 2016 at 05:32:45PM +0300, Enas Ahmad wrote:
> Thanks Ben for the useful answer, following these directions I was able to
> add a new field and was able to successfully create a table entry
> specifying a value for that filed.
>
> However, now I need to verify the packet extraction
On Wed, Jan 06, 2016 at 01:26:58PM +0300, Enas Ahmad wrote:
> I am designing a new protocol for IoT applications, and I would like to
> know if I can extend Open Flow match fields to add a new header field
> designed by my new protocol ?
> Also, can I define a new field for the set-field action ?
Hi,
I am designing a new protocol for IoT applications, and I would like to
know if I can extend Open Flow match fields to add a new header field
designed by my new protocol ?
Also, can I define a new field for the set-field action ?
Thank you very much,
Enas
--
--
13 matches
Mail list logo
