Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

2018-02-23 Thread Han Zhou
On Fri, Feb 23, 2018 at 2:17 PM, Ben Pfaff  wrote:
>
> On Tue, Feb 20, 2018 at 08:56:42AM -0800, Han Zhou wrote:
> > On Tue, Feb 20, 2018 at 8:15 AM, Ben Pfaff  wrote:
> > >
> > > On Mon, Feb 19, 2018 at 11:33:11AM +0100, Daniel Alvarez Sanchez
wrote:
> > > > @Han, I can try rebase the patch if you want but that was
> > > > basically renaming the Address_Set table and from Ben's
> > > > comment, it may be better to keep the name. Not sure,
> > > > however, how we can proceed to address Lucas' points in
> > > > this thread.
> > >
> > > I wouldn't rename the table.  It sounds like the priority should be to
> > > add support for sets of port names.  I thought that there was already
a
> > > patch for that to be rebased, but maybe I misunderstood.
> >
> > I feel it is better to add a new table for port group explicitly, and
the
> > column type can be a set of weak reference to Logical_Switch_Port.
> > The benefits are:
> > - Better data integrity: deleting a lport automatically deletes from the
> > port group
> > - No confusion about the type of records in a single table
> > - Existing Address_Set mechanism will continue to be supported without
any
> > change
> > - Furthermore, the race condition issue brought up by Lucas can be
solved
> > by supporting port-group in IP address match condition in
ovn-controller,
> > so that all addresses in the lports are used just like how AddressSet is
> > used today. And there is no need for Neutron networking-ovn to use
> > AddressSet any more. Since addresses are deduced from lports, the
ordering
> > of deleting/adding doesn't matter any more.
> >
> > How does this sound?
>
> Will we want sets of Logical_Router_Ports later?
At least I don't see any use case in Neutron for router ports since
Security Group is only for VIF ports.

There is another tricky point I see while working on implementation. In
Neutron, SG can be applied to ports across different networks, but in OVN
lports works only on its own datapath, so in ovn-controller we need to be
able to pickup related ports from the port-group when translating lflows
for each datapath. I hope this is not an issue. Otherwise, Neutron plugin
will have to divide the group of ports into sub-groups according to the
lswitch they belong to, which would be a pain.

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


Re: [ovs-discuss] Cannot change vxlan egress (source) ports

2018-02-23 Thread Ben Pfaff
On Fri, Feb 16, 2018 at 12:50:57AM -0300, José Miguel Guzmán wrote:
> Hello
> 
> I need to change the range of source ports for VXLAN tunnels.
> 
> Although I tried with set dst_port to 2000
> # ovs-vsctl add-port br-ovs vxlan3 -- set interface vxlan3 type=vxlan
> options:remote_ip=192.168.111.203 options:dst_port=2
> 
> and egress port range to 2-20001
> # ovs-appctl tnl/egress_port_range 2 20001
> # ovs-appctl tnl/egress_port_range
> Tunnel UDP source port range: 2-20001

tnl/egress_port_range only influences the behavior of the DPDK-based
tunnel implementation in OVS.  If you're using the kernel implementation
of tunneling, it will have no effect.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] invalid Ethertype 0 in flow key

2018-02-23 Thread Ben Pfaff
This is an unusual problem that I haven't seen reported by others.  Is
there anything special about your machine, your kernel, your build,
etc.?

Whether you specify dst_port should not make a difference.  This is
implemented at a low level, so I don't know why it would change the
behavior you see.

On Sat, Feb 17, 2018 at 04:20:36AM +0500, Jamshaid Faisal wrote:
> hmm i got some more info actually
> if i use options:dst_port=x  in vxlan setup command above, i dont get
> those errors in log. It means i have to use dst_port
> however i read this in documents
> 
> "By default, Open vSwitch will use the assigned IANA port for VXLAN, which
> is 4789"
> 
> Whats really going on there, VXLAN works without specifying dst_port but
> with these errors in log.
> so should i use dst_port ?
> 
> On Sat, Feb 17, 2018 at 4:08 AM, Jamshaid Faisal  wrote:
> 
> > I got some more details, Here is exactly how to get it on a clean install
> >
> > rm -rf /etc/openvswitch/conf.db
> > service openvswitch restart
> > ovs-vsctl add-br mybridge
> > ovs-vsctl --may-exist add-port mybridge myport -- set interface myport
> > type=vxlan options:remote_ip=10.1.1.1
> >
> > And there you go, i start getting below lines in /var/log/messages
> >
> > ovs-vswitchd: ovs|1|odp_util(revalidator18)|ERR|invalid Ethertype 0
> > in flow key
> > ovs-vswitchd: ovs|2|odp_util(revalidator18)|ERR|invalid Ethertype 0
> > in flow key
> > ovs-vswitchd: ovs|3|odp_util(revalidator18)|ERR|invalid Ethertype 0
> > in flow key
> > ovs-vswitchd: ovs|4|odp_util(revalidator18)|ERR|invalid Ethertype 0
> > in flow key
> > ovs-vswitchd: ovs|5|odp_util(revalidator18)|ERR|invalid Ethertype 0
> > in flow key
> >
> > What i am doing wrong?
> >
> > On Tue, Feb 13, 2018 at 1:10 AM, Jamshaid Faisal 
> > wrote:
> >
> >> Hello
> >>
> >> Lately i have seen a lot of below messages in log (/var/log/messages). It
> >> is happening no matter which OVS version i use. Below log is from ovs 2.7.2
> >>
> >>
> >> ===
> >> Feb 12 12:03:21 SGP1-1-10 ovs-vswitchd: 
> >> ovs|00135|odp_util(revalidator72)|ERR|Dropped
> >> 27 log messages in last 58 seconds (most recently, 3 seconds ago) due to
> >> excessive rate
> >> Feb 12 12:03:21 SGP1-1-10 ovs-vswitchd: 
> >> ovs|00136|odp_util(revalidator72)|ERR|invalid
> >> Ethertype 0 in flow key
> >> ===
> >>
> >>
> >> They even happens with minimum config without vxlan etc.
> >> I am using XEN and its hot-plug script vif-openvsiwtch. Openvswitch is
> >> compiled with default options.
> >>
> >> What does these messages really mean?
> >>
> >> I dont see any functional issues, VMs have network, VXLAN also works
> >> fine,  But why lot of above messages in log ?
> >>
> >> Please help.
> >>
> >> Regards
> >>
> >>
> >

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

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


Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

2018-02-23 Thread Ben Pfaff
On Tue, Feb 20, 2018 at 08:56:42AM -0800, Han Zhou wrote:
> On Tue, Feb 20, 2018 at 8:15 AM, Ben Pfaff  wrote:
> >
> > On Mon, Feb 19, 2018 at 11:33:11AM +0100, Daniel Alvarez Sanchez wrote:
> > > @Han, I can try rebase the patch if you want but that was
> > > basically renaming the Address_Set table and from Ben's
> > > comment, it may be better to keep the name. Not sure,
> > > however, how we can proceed to address Lucas' points in
> > > this thread.
> >
> > I wouldn't rename the table.  It sounds like the priority should be to
> > add support for sets of port names.  I thought that there was already a
> > patch for that to be rebased, but maybe I misunderstood.
> 
> I feel it is better to add a new table for port group explicitly, and the
> column type can be a set of weak reference to Logical_Switch_Port.
> The benefits are:
> - Better data integrity: deleting a lport automatically deletes from the
> port group
> - No confusion about the type of records in a single table
> - Existing Address_Set mechanism will continue to be supported without any
> change
> - Furthermore, the race condition issue brought up by Lucas can be solved
> by supporting port-group in IP address match condition in ovn-controller,
> so that all addresses in the lports are used just like how AddressSet is
> used today. And there is no need for Neutron networking-ovn to use
> AddressSet any more. Since addresses are deduced from lports, the ordering
> of deleting/adding doesn't matter any more.
> 
> How does this sound?

Will we want sets of Logical_Router_Ports later?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


[ovs-discuss] ERROR: No build ID note found in

2018-02-23 Thread Greenberg, Paul
Encountered the following error when building RPM for RHEL.

Tarball: http://openvswitch.org/releases/openvswitch-2.9.0.tar.gz

$ rpmbuild -bb rhel/openvswitch.spec

...

libtool: warning: remember to run 'libtool --finish /usr/lib64'
 /usr/bin/mkdir -p 
'/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin'
  /bin/sh ./libtool   --mode=install /usr/bin/install -c utilities/ovs-appctl 
utilities/ovs-testcontroller utilities/ovs-dpctl utilities/ovs-ofctl 
utilities/ovs-vsctl ovsdb/ovsdb-tool ovsdb/ovsdb-client vtep/vtep-ctl 
ovn/controller/ovn-controller ovn/controller-vtep/ovn-controller-vtep 
ovn/northd/ovn-northd ovn/utilities/ovn-nbctl ovn/utilities/ovn-sbctl 
ovn/utilities/ovn-trace 
'/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin'
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c utilities/.libs/ovs-appctl 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovs-appctl
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c utilities/.libs/ovs-testcontroller 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovs-testcontroller
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c utilities/.libs/ovs-dpctl 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovs-dpctl
libtool: warning: 'ofproto/libofproto.la' has not been installed in '/usr/lib64'
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c utilities/.libs/ovs-ofctl 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovs-ofctl
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c utilities/.libs/ovs-vsctl 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovs-vsctl
libtool: warning: 'ovsdb/libovsdb.la' has not been installed in '/usr/lib64'
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c ovsdb/.libs/ovsdb-tool 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovsdb-tool
libtool: warning: 'ovsdb/libovsdb.la' has not been installed in '/usr/lib64'
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c ovsdb/.libs/ovsdb-client 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovsdb-client
libtool: warning: 'vtep/libvtep.la' has not been installed in '/usr/lib64'
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c vtep/.libs/vtep-ctl 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/vtep-ctl
libtool: warning: 'ovn/lib/libovn.la' has not been installed in '/usr/lib64'
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c ovn/controller/.libs/ovn-controller 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovn-controller
libtool: warning: 'ovn/lib/libovn.la' has not been installed in '/usr/lib64'
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: warning: 'vtep/libvtep.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c 
ovn/controller-vtep/.libs/ovn-controller-vtep 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovn-controller-vtep
libtool: warning: 'ovn/lib/libovn.la' has not been installed in '/usr/lib64'
libtool: warning: 'ovsdb/libovsdb.la' has not been installed in '/usr/lib64'
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c ovn/northd/.libs/ovn-northd 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovn-northd
libtool: warning: 'ovn/lib/libovn.la' has not been installed in '/usr/lib64'
libtool: warning: 'ovsdb/libovsdb.la' has not been installed in '/usr/lib64'
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c ovn/utilities/.libs/ovn-nbctl 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovn-nbctl
libtool: warning: 'ovn/lib/libovn.la' has not been installed in '/usr/lib64'
libtool: warning: 'ovsdb/libovsdb.la' has not been installed in '/usr/lib64'
libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64'
libtool: install: /usr/bin/install -c ovn/utilities/.libs/ovn-sbctl 
/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovn-sbctl
libtool: warning: 'ovn/lib/libovn.la' has not been installed in '/usr/lib64'
libtool: warning: 'ovsdb/libovsdb.la' has not been installed in '/usr/lib64'
libtool: warning: 'lib/libopenvswitch.la' has not been installed 

Re: [ovs-discuss] Is a new field in flow.h necessary for matching on a custom v6 extension header?

2018-02-23 Thread Ben Pfaff
Ultimately, I expect a P4-based solution, in which the controller
supplies a P4 program that extracts the fields that it is interested in.
This is my big project for OVS 2.10.  (I don't know how successful I'll
be yet.)

On Fri, Feb 23, 2018 at 12:37:40AM +0100, Alan Kayahan wrote:
> I understand that there must be a construct in the struct flow, and
> introducing a new be32 will save the day for me. However looking at this
> from a broader perspective, say matching on the fields of any v6 extension
> header made into the OF specification, neither adding individual fields nor
> adding every v6 extension header into the struct flow looks elegant to me.
> What do you think?
> 
> 2018-02-21 17:10 GMT+01:00 Ben Pfaff :
> 
> > On Mon, Feb 19, 2018 at 06:15:30PM +0100, Alan Kayahan wrote:
> > > I have a custom v6 extension header, in which I would like to perform an
> > > LPM match on only one 32bit field.
> > >
> > > Since an extension header is technically not a new field, do I still need
> > > to introduce anything in the struct flow?
> >
> > Without anything in struct flow, how do you propose to match on it?
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss