Hi,
I saw this just fixed days ago:
http://openvswitch.org/pipermail/dev/2015-November/062060.html
Han
On Mon, Nov 9, 2015 at 11:24 PM, shengping.xu
wrote:
> Hello everyone:
> After testing, there may be a memory lead problem in function
> ovsthread_key_destruct__,for details,see e-mail attach
> On Nov 14, 2015, at 9:26 AM, Bhargava N.B wrote:
>
> I expect to see some logs regarding the control flow in
> /var/logs/openvswitch, but I can see that the folder is not updated at all.
> I am more interested to see any logs from the VLOG_DBG or VLOG_INFO from the
> files like ovs-ofctl.c e
Thanks for your reply.I also think it is memory causing this issue.When I use a
raspberry pi with 1G RAM, it can build and test successfully. But it also
failed with several tests occasionally. I tried to build and test several
times, and it finally succeed.Thanks.
Zhao Jun
> From: joestrin...
Hi Ben,
Thanks for your reply!
Seems the action "write_metadata" is not allowed to set before "Controller", so
I tried to use " load:->NXM_NX_REG*" instead, to pass any data to
controller and it worked.
I think the usage of metadata is very limited if so.
Pls correct me.
Thanks
Chao
-
This is the relevant commit:
https://github.com/openvswitch/ovs/commit/b953042214201e2693a485a8ba8b19f69e5bdf34
Unfortunately, it's not very obvious from the commit message that this is a
bug fix.
On Sunday, November 8, 2015, ZHANG Zhiming
wrote:
> Hi Gross,
>
> Thank you very much.
>
> You sav
Hello everyone:
After testing, there may be a memory lead problem in function
ovsthread_key_destruct__,for details,see e-mail attachment.Thanks!
5ABUW%U08Y]VMP{}1DK%553.png
Description: Binary data
___
discuss mailing list
discuss@openvswitch.org
Hello everyone:
After testing, there may be a memory lead problem in function
ovsthread_key_destruct__,for details,see e-mail attachment.Thanks!
5ABUW%U08Y]VMP{}1DK%553.png
Description: Binary data
___
discuss mailing list
discuss@openvswitch.org
The first packet of a flow goes to user space, then after classification in
the pipeline a
specific matching cache entry is added in the kernel (two cache types:
megaflow and microflow, you can read more about in the link below) this
entry has the matching keys and the actions to perform.
The next
Pardon my ignorance then, but it seems I got it wrong when I thought the
main flow tables were in the Kernel. Then, if the main flows are stored in
userspace, does that mean the data packets arrive directly to the
userspace client code and treated there? Instead of arriving to some
listener proces
