Thanks for the clarification.
Regards
KK
On 20 May 2011 16:44, Ben Pfaff wrote:
> I pushed the patch.
>
> You can tell that both "cookie" members are in network byte order by
> looking at the types: both are declared as type ovs_be64 (the "be"
> stands for "big-endian").
>
> On Fri, May 20, 2011
I pushed the patch.
You can tell that both "cookie" members are in network byte order by
looking at the types: both are declared as type ovs_be64 (the "be"
stands for "big-endian").
On Fri, May 20, 2011 at 04:41:21PM -0700, kk yap wrote:
> Hi Ben,
>
> The patch works! Thanks.
>
> One strange t
Hi Ben,
The patch works! Thanks.
One strange thing is the lack of htonll. It would seems like fr is in
host order and ofr is in network order, so the function is needed.
However, adding the function gives the wrong result. FYI.
Regards
KK
On 20 May 2011 16:08, Ben Pfaff wrote:
> On Fri, May
On Fri, May 20, 2011 at 04:03:49PM -0700, kk yap wrote:
> We are sending flow_mod with some cookie value (e.g., deadbeef), but
> all the flow_removed returns with cookie 0. A sample tcpdump of the
> OpenFlow control traffic is attached.
I like bugs that are easy to track down. Please try this pa
Hi,
We are back! :P
We are sending flow_mod with some cookie value (e.g., deadbeef), but
all the flow_removed returns with cookie 0. A sample tcpdump of the
OpenFlow control traffic is attached.
The OVS version we are using has last commit
c64540e3fe43a83bbe8687c53fb7fdec95b94195. It was prev
