Re: [ovs-dev] datapath forwarding

2015-08-07 Thread Raul Suarez Marin
Hello, Thank you for replying. I managed to see printk() on dmesg, I was debugging wrong (I'm new in this kernel-space area). I traced my mistake and I found it, thank you very much for your help Kind regards, Raúl 2015-08-06 20:14 GMT+02:00 Joe Stringer : > --verbose makes the ovs-ofctl proce

Re: [ovs-dev] datapath forwarding

2015-08-06 Thread Joe Stringer
--verbose makes the ovs-ofctl process more verbose by allowing the VLOG_DBG() functions to print to the terminal. For kernel debugging, you want printk() or OVS_NLERR(), and these will print to the kernel log (which shows up in dmesg). If you're not able to see it there, then it may mean that your

Re: [ovs-dev] datapath forwarding

2015-08-06 Thread Raul Suarez Marin
Is there a way of adding messages myself and see them thorugh --verbose? I was told that "printk()" did that but I'm not able to see it anywhere :( Thank you for your answer, Kind regards, Raúl 2015-08-05 22:40 GMT+02:00 Joe Stringer : > On 5 August 2015 at 13:02, Raul Suarez Marin > wrote: >

Re: [ovs-dev] datapath forwarding

2015-08-05 Thread Joe Stringer
On 5 August 2015 at 13:02, Raul Suarez Marin wrote: > Hello everyone, > > I am developing a new match option in the datapath. I implemented almost > everything already, but I am missing something and I don't know what nor > what is next step. > > Adding the flow directly to the datapath gives the

[ovs-dev] datapath forwarding

2015-08-05 Thread Raul Suarez Marin
Hello everyone, I am developing a new match option in the datapath. I implemented almost everything already, but I am missing something and I don't know what nor what is next step. Adding the flow directly to the datapath gives the following error: ovs-dpctl: updating flow table (Invalid argument

[ovs-dev] datapath forwarding

2015-08-03 Thread Raul Suarez Marin
Hello, I am developing a new match option for openvswitch and I would like that it runs through the datapath without need of user-space. I'm not really sure if I missed something but this is what happens: (1) First incomming packet is processed correctly (processed + stats updated) (2) Following