[ovs-discuss] Windows unit test CI unavailable

[Alin Serdean]

Hi,

The Windows unit test CI will be down for approximately one month. We are 
moving the servers to a different zone.

I will run unit tests daily and report bugs on 
b...@openvswitch.org (in case of failures) until 
they are online.

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

Re: [ovs-discuss] [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966 1968 1975 1977 1984 1986 1993 1995 2001 2002 2003 2004 2006 2011 2013 2020 2022 2029 2031 2038 2040 2047 2049 2056 2058 2

[Alin Serdean]

> -Original Message-
> From: Lance Richardson [mailto:lrich...@redhat.com]
> Sent: Tuesday, August 15, 2017 4:45 AM
> To: Alin Serdean 
> Cc: b...@openvswitch.org; Alin Balutoiu
> ; Terry Wilson ;
> Russell Bryant 
> Subject: Re: [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966 1968
> 1975 1977 1984 1986 1993 1995 2001 2002 2003 2004 2006 2011 2013 2020 2022
> 2029 2031 2038 2040 2047 2049 2056 2058 2065 2067 2074 2076 2083 2085 2092
> 2094 2101 2103 2110 2112 2119 21...
> 
> > From: "Alin Serdean" 
> > To: b...@openvswitch.org, "Alin Balutoiu"
> > 
> > Cc: "Terry Wilson" , "Lance Richardson"
> > , "Russell Bryant" 
> > Sent: Monday, August 14, 2017 8:45:01 PM
> > Subject: [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966
> > 1968 1975 1977 1984 1986 1993 1995 2001 2002
> > 2003 2004 2006 2011 2013 2020 2022 2029 2031 2038 2040 2047 2049 2056
> > 2058 2065 2067 2074 2076 2083 2085 2092 2094
> > 2101 2103 2110 2112 2119 2121 2128
> >
> > To: 
> >Subject: [openvswitch 2.8.90] testsuite: 537 539 541 545 765 767 1966 
> > 1968
> >1975 1977 1984 1986 1993 1995 2001 2002 2003 2004 2006 2011 2013 2020
> >2022 2029 2031 2038 2040 2047 2049 2056 2058 2065 2067 2074 2076 2083
> >2085 2092 2094 2101 2103 2110 2112 2119 2121 2128 2130 2136 2138 2140
> >2148 2151 2238 2244 2247 2250 failed
> >
> > After patch:
> >
> https://github.com/openvswitch/ovs/commit/e7164d96bcbcf79044a93f6e7a
> cc
> > 68f05d8e3945 a lot of the python3 tests are failing.
> >
> > This is probably due to:
> > +Traceback (most recent call last):
> > +  File "../.././appctl.py", line 75, in 
> > +main()
> > +  File "../.././appctl.py", line 60, in main
> > +err_no, error, result = client.transact(args.command, args.argv)
> > +  File "c:\ovs\python\ovs\unixctl\client.py", line 39, in transact
> > +error, reply = self._conn.transact_block(request)
> > +  File "c:\ovs\python\ovs\jsonrpc.py", line 326, in transact_block
> > +error, reply = self.recv_block()
> > +  File "c:\ovs\python\ovs\jsonrpc.py", line 309, in recv_block
> > +error, msg = self.recv()
> > +  File "c:\ovs\python\ovs\jsonrpc.py", line 273, in recv
> > +data = data.decode('utf-8')
> > +AttributeError: 'str' object has no attribute 'decode'
> >
> > Also using UTF-8 strings in Windows shells proves to be a bit of challenge.
> >
> > Me and @Alin Balutoiu are looking over changes needed on the Windows
> > side as well.
> >
> > Since Python isn't quite my cup of tea I would like if you can oversee
> > the patches that he will send out.
> >
> > Thanks,
> > Alin.
> >
> 
> Hi Alin,
> 
> It seems that for the Python3 non-windows, self.stream.recv() returns
> socket.recv(), which always has a type of "bytes". For the windows case,
> self.stream.recv() returns
> get_decoded_buffer(recvBuffer) from python/ovs/winutils.py, which does:
> 
>return bytes(recvBuffer).decode("utf-8")
> 
> So for the windows Python3 case, the type of the value returned by
> self.stream.recv() will always be "str".
> 
> I'm not sure why the windows case needs to do the utf-8 decode at the
> stream layer, but it would be nice if self.stream.recv() returned a consistent
> type that was independent of the OS.
> 
> I'm happy to help, but I will be travelling tomorrow and will probably not be
> able to look any deeper until Wednesday.
> 
> I don't know if such a thing exists, but e.g. a Vagrant setup that could build
> ovs and run the tests would be a huge help in avoiding this kind of breakage
> (just a thought...)
> 
> Regards,
> 
>Lance
Hi Lance,

@Alin Balutoiu sent out two patches: https://patchwork.ozlabs.org/patch/801393/ 
 ; https://patchwork.ozlabs.org/patch/801394/ 
which should make the code a bit more OS independent. Can you please review 
them when you have time?

Regarding the Vagrant setup it is a great idea. The only downside, I have no 
idea how it deals with Windows images.
I will look into if it is possible to setup Vagrant using Nano images (lowest 
disk requirement) because this would help a lot in the future.

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

Re: [ovs-discuss] getting build errors while building ovs2.7.0

[Joe Stringer]

On 11 August 2017 at 11:52, Prem Shankar Sharma via discuss
 wrote:
> Hi,
> I'm getting some build errors while trying to build ovs2.7.0 on redhat 7.2.
> I cloned 2.7.0 from git and tried to run - make and make modules_install (to
> build kernel module). The output of both of them is reporting some issues
> like:

Hi Prem,

The kernel module that comes with OVS 2.7.0 doesn't support Redhat 7.2
- RHEL7.2 is newer than OVS 2.7. You can use the module that is
distributed with RHEL (and not compile the version from OVS tree), or
wait for the upcoming OVS 2.8 release that is expected later this
month. Alternatively if you are happy running on the master version of
OVS, you might consider just cloning and building the top of tree from
github.

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

Re: [ovs-discuss] OVS megaflows

[Joe Stringer]

The FAQ is referring to megaflows as well, the reasons are the same.
Neither microflows nor megaflows can be pre-populated.

On 14 August 2017 at 00:35, Sara Gittlin  wrote:
> I  understand that this citation refers to the kernel microflows  tables.
> the kernel megaflows table *can be* pre-populated. Correct ?
> Sara
>
> On Mon, Aug 14, 2017 at 9:31 AM, Sara Gittlin  wrote:
>> Thanks you Joe
>> the following citation is in a contradiction to the idea of
>> pre-populating megaflows in kernel datapath .
>> this is from  http://docs.openvswitch.org/en/latest/faq/design/
>>
>> "Q: Can OVS populate the kernel flow table in advance instead of in
>> reaction to packets?
>>
>> A: No. There are several reasons:
>>
>> Kernel flows are not as sophisticated as OpenFlow flows, which means
>> that some OpenFlow policies could require a large number of kernel
>> flows. The “conjunctive match” feature is an extreme example: the
>> number of kernel flows it requires is the product of the number of
>> flows in each dimension.
>> With multiple OpenFlow flow tables and simple sets of actions, the
>> number of kernel flows required can be as large as the product of the
>> number of flows in each dimension. With more sophisticated actions,
>> the number of kernel flows could be even larger.
>> Open vSwitch is designed so that any version of OVS userspace
>> interoperates with any version of the OVS kernel module. This forward
>> and backward compatibility requires that userspace observe how the
>> kernel module parses received packets. This is only possible in a
>> straightforward way when userspace adds kernel flows in reaction to
>> received packets."
>>
>> Thanks in advance - Sara
>>
>> On Mon, Jul 24, 2017 at 10:58 PM, Joe Stringer  wrote:
>>> On 23 July 2017 at 06:37, Sara Gittlin  wrote:
 Hello,
 I understand that there is a support for megaflows in the kernel and 
 netlink.
 I also understand that there is no megaflow implementation in ofproto.
 i.e. there is no implementation of compressing (if possible) all flows
 in ofproto table to megaflows and installing it in the datapath. is
 that correct ?
>>>
>>> That's right - rather than pre-populating a representation of the
>>> entire OpenFlow state, the ofproto-dpif implementation uses an
>>> "upcall" model where the datapath acts as a cache for forwarding
>>> behaviour, and the cache is populated on-demand as traffic arrives.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS megaflows

[Sara Gittlin]

I  understand that this citation refers to the kernel microflows  tables.
the kernel megaflows table *can be* pre-populated. Correct ?
Sara

On Mon, Aug 14, 2017 at 9:31 AM, Sara Gittlin  wrote:
> Thanks you Joe
> the following citation is in a contradiction to the idea of
> pre-populating megaflows in kernel datapath .
> this is from  http://docs.openvswitch.org/en/latest/faq/design/
>
> "Q: Can OVS populate the kernel flow table in advance instead of in
> reaction to packets?
>
> A: No. There are several reasons:
>
> Kernel flows are not as sophisticated as OpenFlow flows, which means
> that some OpenFlow policies could require a large number of kernel
> flows. The “conjunctive match” feature is an extreme example: the
> number of kernel flows it requires is the product of the number of
> flows in each dimension.
> With multiple OpenFlow flow tables and simple sets of actions, the
> number of kernel flows required can be as large as the product of the
> number of flows in each dimension. With more sophisticated actions,
> the number of kernel flows could be even larger.
> Open vSwitch is designed so that any version of OVS userspace
> interoperates with any version of the OVS kernel module. This forward
> and backward compatibility requires that userspace observe how the
> kernel module parses received packets. This is only possible in a
> straightforward way when userspace adds kernel flows in reaction to
> received packets."
>
> Thanks in advance - Sara
>
> On Mon, Jul 24, 2017 at 10:58 PM, Joe Stringer  wrote:
>> On 23 July 2017 at 06:37, Sara Gittlin  wrote:
>>> Hello,
>>> I understand that there is a support for megaflows in the kernel and 
>>> netlink.
>>> I also understand that there is no megaflow implementation in ofproto.
>>> i.e. there is no implementation of compressing (if possible) all flows
>>> in ofproto table to megaflows and installing it in the datapath. is
>>> that correct ?
>>
>> That's right - rather than pre-populating a representation of the
>> entire OpenFlow state, the ofproto-dpif implementation uses an
>> "upcall" model where the datapath acts as a cache for forwarding
>> behaviour, and the cache is populated on-demand as traffic arrives.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] How to make OVS working with IVSHMEM ?

[Bodireddy, Bhanuprakash]

>Hello, I've encountered a problem with running ovs with IVSHMEM.
>
>I've followed the guide of INSTALL.DPDK.md of ovs-2.5.0 to use IVSHMEM.
>
>Firstly, I started ovs-vswitchd using "./sbin/ovs-vswitchd --dpdk -c 0x1 -n 4 
>--
>proc-type=primary -- --pidfile --detach", and I added dpdk
>ports(dpdk0,dpdk1) and dpdk ring(dpdkr0) to ovs.
>
>Then, I started ./openvswitch-2.5.0/tests/test-dpdkr using "./test-dpdkr -c 1 -
>n 4 --proc-type=secondary -- -n 0", but the EAL initialization of this program
>was stucked after printing "EAL: Detected 16 lcore(s)" to stdout.
>
>Does anybody has successful experience with running ovs with IVSHMEM?
>Please share with me. Many thanks!!!

Refer the link here
https://github.com/openvswitch/ovs/blob/branch-2.6/INSTALL.DPDK-ADVANCED.md#ovstc

I wrote this documentation and have a section(5.2) dedicated for IVSHMEM. With 
the steps
mentioned in section 5.2,  I could successfully verify IVSHMEM back in 2.6 
release. You should
patch Qemu 2.2 as mentioned in the install guide.

Hope it helps you!

- Bhanuprakash.

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