Re: [ovs-discuss] Using libopenvswitch in C++

2017-07-30 Thread Ben Pfaff
On Sun, Jul 30, 2017 at 08:33:41AM -0700, Ben Warren via discuss wrote:
> Hello Xiao,
> 
> > On Jul 29, 2017, at 11:30 PM, Xiao Liang  wrote:
> > 
> > Hi,
> > 
> > I've encountered some problems building a controller with
> > libopenvswitch in C++. Although they can be solved by some hacks, I
> > want to know if OVS is meant to be used in such case.
> > 
> I don’t think there are very many consumers of libopenvswitch.  It was only 
> added a year and a half ago, and is rarely mentioned in discussions.  The 
> exportability of OVS is definitely geared towards C (and, in my case golang), 
> so it’s more likely the case that people simply weren’t thinking about C++ at 
> the time.
> > 1. In include/openvswitch, some headers are wrapped with 'extern "C"'
> > (e.g. ofpbuf.h), while some are not (e.g. ofp-util.h).
> > 2. The identifier "public" in "struct ofputil_packet_in_private"
> > conflicts with C++ keyword. Not sure if there're others.
> > 3. Private and public declarations (like the
> > ofputil_packet_in_private) could be separated to different files. Also
> > some more APIs (like rconn) could be extracted from lib directory?
> > 
> I expect that the maintainers would accept patches to make the code more C++ 
> friendly, as long as you don’t break the C/golang support.  I can test the 
> latter.

I think that Open vSwitch can do better here.

I sent out a series, would you mind taking a look?  It starts here:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/336426.html
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] Using libopenvswitch in C++

2017-07-30 Thread Ben Warren via discuss
Hello Xiao,

> On Jul 29, 2017, at 11:30 PM, Xiao Liang  wrote:
> 
> Hi,
> 
> I've encountered some problems building a controller with
> libopenvswitch in C++. Although they can be solved by some hacks, I
> want to know if OVS is meant to be used in such case.
> 
I don’t think there are very many consumers of libopenvswitch.  It was only 
added a year and a half ago, and is rarely mentioned in discussions.  The 
exportability of OVS is definitely geared towards C (and, in my case golang), 
so it’s more likely the case that people simply weren’t thinking about C++ at 
the time.
> 1. In include/openvswitch, some headers are wrapped with 'extern "C"'
> (e.g. ofpbuf.h), while some are not (e.g. ofp-util.h).
> 2. The identifier "public" in "struct ofputil_packet_in_private"
> conflicts with C++ keyword. Not sure if there're others.
> 3. Private and public declarations (like the
> ofputil_packet_in_private) could be separated to different files. Also
> some more APIs (like rconn) could be extracted from lib directory?
> 
I expect that the maintainers would accept patches to make the code more C++ 
friendly, as long as you don’t break the C/golang support.  I can test the 
latter.
> Thanks,
> Xiao
> 

regards,
Ben



smime.p7s
Description: S/MIME cryptographic signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] Issue with offloading OVS flows into Mellanox-4 cards

2017-07-30 Thread Roi Dayan
Thanks for the info.



From: Sugu Deepthy [mailto:deepthysug...@gmail.com]
Sent: Thursday, July 27, 2017 12:58 PM
To: Roi Dayan 
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] Issue with offloading OVS flows into Mellanox-4 cards


Hi Roi,
Thank you for the help,
Upgraded the firmware to 14.20 and used latest kernel(4.10) in VM.
Now its working correctly. I can forward packets between VM and physical ports 
in the NIC. The oflloaded flows are showing in the OVS.

Few suggestions while preparing the installation document for hardware offload.
1) Must need to provide minimum kernel version to use this feature.
2) The default MLNX firmware is not supporting the hardware offload for some 
reason. Must specify what version of firmware and supported NICs
3) Even though I use the ethernet NIC, I have to install the IB verbs src in 
the VM for attaching the VF to the DPDK. Not sure why this is a prerequisite

Once again thank for the suggestions to make it working. :)

On Mon, Jul 24, 2017 at 9:05 AM, Sugu Deepthy 
> wrote:


On Mon, Jul 24, 2017 at 5:46 AM, Roi Dayan 
> wrote:



[Sugu] I upgraded the system and now I dont see this error anymore.
Instead I see this

[ 1103.216355] mlx5_3:wait_for_async_commands:722:(pid 3097): done with
all pending requests
[ 1115.954770] mlx5_core :07:00.0: mlx5_cmd_check:697:(pid 3477):
QUERY_VPORT_COUNTER(0x770) op_mod(0x0) failed, status bad system
state(0x4), syndrome (0x368b01)
[ 1115.954902] mlx5_core :07:00.0: mlx5_cmd_check:697:(pid 3477):
QUERY_VPORT_COUNTER(0x770) op_mod(0x0) failed, status bad system
state(0x4), syndrome (0x368b01)

I am getting this error back to back for every command(2 entry for each
command as I have 2 VFs, may be?)
starting from unbind, devlink, ethtool and starting the VM.
And inside the VM the VFs are not bound to any driver either. Is there
any wrong with the NIC?


looks like the syndrome you get is caused by querying a counter while
the HCA is not yes configured properly.
can you verify you are using the latest firmware?
can you verify the steps you do? did you enable sriov and moved to
switchdev mode?
[Sugu] Ok. SR-IOV is enabled on the board. and the device is moved to
switchdev mode though it throws the error that shown above.

The firmware version of the card is
# ethtool -i ens786f0
driver: mlx5_core
version: 3.0-1 (January 2015)
firmware-version: 14.17.2032
expansion-rom-version:
bus-info: :07:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes

Do you think this version firmware cannot support the offload??
Will try to install the latest firmware and keep you posted.







I verfied that the ports named eth1, eth2, eth3 and et4 are
created for
my vfs, when
I ran the commands 'devlink dev eswitch set pci/:07:00.0 mode
switchdev' and
'devlink dev eswitch set pci/:07:00.1 mode switchdev'

The detailed error in dmesg are given below,
[ 1245.941287] mlx5_core :07:00.0: mlx5_cmd_check:697:(pid
3107):
QUERY_VPORT_COUNTER(0x770) op_mod(0x0) failed, status bad system
state(0x4), syndrome (0x368b01)
[ 1245.941478] mlx5_core :07:00.1: mlx5_cmd_check:697:(pid
3107):
QUERY_VPORT_COUNTER(0x770) op_mod(0x0) failed, status bad system
state(0x4), syndrome (0x368b01)

Please note I couldn't run the "inline-mode transport" command
as its
not supported.


maybe you need newer iproute package. try to install latest upstream.

[Sugu]
I am using latest Ubuntu release


No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu Artful Aardvark (development branch)
Release:17.10
Codename:   artful

and my kernel is
4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:03:41 UTC 2017 x86_64
x86_64 x86_64 GNU/Linux

And still it need to install the newer iproute package additonally? Is
that the requirement to use the hardware offload in OVS?
And my iproute version is
ip -V
ip utility, iproute2-ss161212
Can you share which version of iproute you use for the testing?

I'm using latest upstream. I'm not sure if all needed patches are in
Ubuntu distro.
my versions looks like this: ip utility, iproute2-ss170501

if you have devlink and you can change mode to switchdev without an
error then it's ok to start going.
[Sugu] Ok. Thank you for confirming.






We still need to work on docs for this feature but for now I
documented it a little here:


[ovs-discuss] Using libopenvswitch in C++

2017-07-30 Thread Xiao Liang
Hi,

I've encountered some problems building a controller with
libopenvswitch in C++. Although they can be solved by some hacks, I
want to know if OVS is meant to be used in such case.

1. In include/openvswitch, some headers are wrapped with 'extern "C"'
(e.g. ofpbuf.h), while some are not (e.g. ofp-util.h).
2. The identifier "public" in "struct ofputil_packet_in_private"
conflicts with C++ keyword. Not sure if there're others.
3. Private and public declarations (like the
ofputil_packet_in_private) could be separated to different files. Also
some more APIs (like rconn) could be extracted from lib directory?

Thanks,
Xiao
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss