Re: [ovs-discuss] packet_type=legacy_l3 gre tunnel does not work
On Sat, 20 Oct 2018 at 01:37, Gregory Rose wrote:
>
> On 10/18/2018 10:28 PM, Yousong Zhou wrote:
> > On Fri, 19 Oct 2018 at 01:13, Gregory Rose wrote:
> >> On 10/17/2018 6:01 AM, Yousong Zhou wrote:
> >>
> >> I tried to use ip-over-gre with openvswitch 2.8.4, but no "ip proto
> >> 47" traffic can be seen with tcpdump. Later I added a WARN_ON_ONCE(1)
> >> line just before the "goto drop" statement in ovs_vport_send() and it
> >> was triggered right away thus pinpointed the problem.
> >>
> >> It looks to me openvswitch linux kernel datapath always create
> >> ARPHRD_IPGRE device and never set dev->type to ARPHRD_NONE. Please
> >> correct me if this is not the case. The ovs-vswitchd.conf.db doc says
> >> setting packet_type=legacy_l3 should work. I am trying to figure
> >> what's the missing piece.
> >>
> >>
> >> Openvswitch 2.8.4 depends on the built-in gre kernel module and it is true
> >> that
> >> module will always set the device type to ARPHRD_IPGRE upon initial
> >> creation
> >> but if the tunnel is set to a metadata type tunnel then the device type
> >> should
> >> be reset to ARPHRD_NONE.
> >>
> >>
> >> From ../net/ipv4/ip_gre.c:L1037
> >> if (data[IFLA_GRE_COLLECT_METADATA]) {
> >> struct ip_tunnel *t = netdev_priv(dev);
> >>
> >> t->collect_md = true;
> >> if (dev->type == ARPHRD_IPGRE)
> >> dev->type = ARPHRD_NONE;
> >> }
> >>
> >> https://elixir.bootlin.com/linux/v4.6/source/net/ipv4/ip_gre.c#L1037
> >>
> >> Perhaps that code is not being hit?
> > No, nl_attr *data[] was zeroed out in gretap_fb_dev_create().
>
> And you are sure there is no subsequent call to ipgre_netlink_parms()?
gretap_fb_dev_create() will call ipgre_newlink() with zeroed out
nlattr *tb[] and NULL as nlattr *data[]
ipgre_newlink() then calls ipgre_netlink_params() which returns
immediately when data == NULL
By the way, I can now get vxlan to carry L3 packets by setting
options:exts=gpe. LISP is still no go as the openvswitch
implementation seems to provide no way to change dev->type =
ARPHRD_NONE.
yousong
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Tuning ovs
On Fri, Oct 19, 2018 at 07:26:14PM +, Srinivas via discuss wrote: > Hello all,We are starting with ovs and want to use it as > a) a L2 switch with vlan tagging on the guest vm ports.b) no openflow rules > will be configured.c) We will have 4 -5 bridges created on the system with > each bridge having a corresponding bond interface along with the guest > vtap's. > Given the above, how do we tune ovs-vsctl parameters.?Does each bridge > correspond to a data path? If so what should we set the > other-config:n-handler-threads and other-config:n-revalidator-threads to? > > We want to make sure the ovs-vswitchd starts off with the right number of > threads. We try to make OVS have good defaults, so that it isn't necessary to do this kind of configuration at all. I recommend testing the performance before considering any tuning. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Tuning ovs
Hello all,We are starting with ovs and want to use it as a) a L2 switch with vlan tagging on the guest vm ports.b) no openflow rules will be configured.c) We will have 4 -5 bridges created on the system with each bridge having a corresponding bond interface along with the guest vtap's. Given the above, how do we tune ovs-vsctl parameters.?Does each bridge correspond to a data path? If so what should we set the other-config:n-handler-threads and other-config:n-revalidator-threads to? We want to make sure the ovs-vswitchd starts off with the right number of threads. truly, Srinivas. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Starting OVS w/ DPDK ...
Hi,
On Mon, Oct 08, 2018 at 11:52:24AM +0200, Andrzej Ostruszka wrote:
> First of all thank you Flavio for your reply and sorry for late reply
> but I had to switch to something else. Now I resume my ovs ramp up and
> have some additional problems.
>
> My goal is actually to measure performance gain resulting from
> offloading of flow matching to HW. I started with Marvell (even though
> it does not support at the moment RSS+MARK action in DPDK flow API)
> since I thought that if I get it up and running that would be a good
> starting point for adding support for flow matching offload to Marvell
> PMD. However I do have problems even with what seems to be already
> supported.
>
> For the moment I suspend the starting of OVS/DPDK on Marvell PMD and I'm
> trying to bring up the OVS with Mellanox MLX5 PMD. That should be
> supported according to the documentation however I fail to bring it up.
> Maybe there is something very basic that I get wrong so I'd like to
> solicit some help to first start OVS/DPDK on this card (MCX516A-CDAT).
> Once I get this up and running I'll move to Marvell PMDs.
>
> Let me shortly describe my attempt - maybe you'll spot something wrong.
> 1. I compile and install DPDK and test if testpmd has no problems
> (output at the end [1] in order to not clutter this e-mail too much).
>
> 2. Then I configure ovs
>
> ./configure --with-dpdk=$HOME/dpdk-install/usr/local
> --with-linux=/lib/modules/$(uname -r)/build LIBS="-libverbs -lmlx5"
>
> and install it.
>
> 3. I tell OVS to initialize DPDK
>
> # ovs-vsctl get Open_vSwitch . other_config
> {dpdk-init="true"}
>
> 4. I start it (without any bridge)
>
> # ovs-ctl --delete-bridges start
>
> * Starting ovsdb-server
> * system ID not configured, please use --system-id
> * Configuring Open vSwitch system IDs
> Zone 0: name:, IO:0x5e9b6000, len:0x34900,
> virt:0x7f8dd29b6000, socket_id:0, flags:0
> * Starting ovs-vswitchd
> * Enabling remote OVSDB managers
>
> 5. Then I attach to ovs-vswitchd in gdb and set breakpoint in
> rte_eal_hotplug_add
>
> 6. Then I add bridge and first DPDK port
>
> # ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
> # ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk
> options:dpdk-devargs=08:00.0
>
> 7. In the debugger I step through until I get to pci_find_device() and
> in there the comparison function used is 'cmp_detached_dev_name()' which
> checks for dev->drive to be NULL and in my case it is not as it points
> to mlx5 driver:
>
> (gdb) p name
> $23 = 0x262c250 "08:00.0"
> (gdb) p *dev
> $24 = {next = {tqe_next = 0x0, tqe_prev = 0x0}, name = 0x25fa5c0 "08:00.0",
> driver = 0xc96b30 , numa_node = 0, devargs = 0x25fa5a0}
> (gdb) n
> 55 return 1;
>
> and as a result it fails to add port:
>
> ovs-vsctl: Error detected while setting up 'dpdk-p0': Error attaching
> device '08:00.0' to DPDK. See ovs-vswitchd log for details.
> ovs-vsctl: The default log directory is "/usr/local/var/log/openvswitch".
>
> and in there the confirmation from DPDK:
>
> 2018-10-08T09:38:28.234Z|00058|dpdk|ERR|EAL: Cannot find unplugged
> device (08:00.0)
> 2018-10-08T09:38:28.234Z|00059|netdev_dpdk|WARN|Error attaching device
> '08:00.0' to DPDK
> 2018-10-08T09:38:28.234Z|00060|netdev|WARN|dpdk-p0: could not set
> configuration (Invalid argument)
>
> So basically port seems to be attached (to correct driver) but somehow
> detached port is searched for. Seems very much like some config problem
> but I don't know OVS enough to figure it out.
>
> So I'd still appreciate some help in bringing OVS w/ DPDK up.
I've not tried Mellanox myself in a while now, but I found a piece of
documentation that you might have missed:
Documentation/howto/dpdk.rst:
[...]
Some NICs (i.e. Mellanox ConnectX-3) have only one PCI address associated with
multiple ports. Using a PCI device like above won't work. Instead, below usage
is suggested::
$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0
type=dpdk \
options:dpdk-devargs="class=eth,mac=00:11:22:33:44:55"
$ ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1
type=dpdk \
options:dpdk-devargs="class=eth,mac=00:11:22:33:44:56"
[...]
> > BTW the bridge 'br0' also needs to be in the userspace DP.
>
> Ohh, that seems to be in contrast to what this doc:
> http://docs.openvswitch.org/en/latest/howto/dpdk/
> seems to suggest. It tells that the bridge has to be netdev (or maybe I
> don't understand what the 'netdev' datapath type is).
That is correct.
--
Flavio
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] time for another LTS?
On Fri, Oct 19, 2018 at 02:53:53PM -0300, Flavio Leitner wrote: > On Fri, Oct 19, 2018 at 08:23:37AM -0700, Ben Pfaff wrote: > > On Fri, Oct 19, 2018 at 11:48:07AM +, Stokes, Ian wrote: > > > > On 10/18/2018 10:46 PM, Ben Pfaff wrote: > > > > > I've had a number of queries from folks lately about our roadmap for > > > > > LTS releases. It has, indeed, been a long time since we've had a > > > > > long-term support release (the current LTS is 2.5). Usually, we've > > > > > done LTS releases before some kind of big architectural change, etc., > > > > > and so we've had no real internal pressure within the project to do it > > > > > for a while. But it might be a good signal to the community to bring > > > > > the LTS release forward. > > > > > > > > > > What does everyone think about making the next (2.11) release an LTS? > > > > > > > > > > > > > I think it's a good idea. The current LTS is quite old now, especially > > > > for > > > > the DPDK datapath. There is a new DPDK LTS coming out in November which > > > > should be in for OVS 2.11, so it would be a nice combination for a user > > > > to > > > > have LTS support for both. > > > > > > +1 > > > > > > With regards backporting support for LTS releases, I take it LTS takes > > > priority over non LTS branches, that would be the only difference I would > > > think? > > > > Yes, basically we should try harder to backport to LTS branches. > > > > > In fairness I think the community is pretty good as is for backporting > > > bug fixes for all branches. > > > > We do a pretty good job of it most of the time. The main driver for LTS > > releases has been big OVS internal changes that are likely to break > > things. By doing an LTS release just before a version with those kinds > > of changes, we gave our users something to confidently fall back on if > > the next release was a little more unstable--not that we ever aim for > > that, but it happens sometimes. We haven't had that kind of big change > > recently, so we haven't had a natural impetus to release an LTS--and for > > the same reason, it's been easy to backport most fixes because there > > haven't been sweeping changes across the tree. > > What comes to mind is if OVN manages to split up from OVS soon. > Wouldn't be easier if OVN, as a separated project, requires > an OVS LTS version? If so, then 2.11 might not be the best one. That's a good point. It would be reasonable to designate the first version required by the split OVN as LTS. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] time for another LTS?
On Fri, Oct 19, 2018 at 08:23:37AM -0700, Ben Pfaff wrote: > On Fri, Oct 19, 2018 at 11:48:07AM +, Stokes, Ian wrote: > > > On 10/18/2018 10:46 PM, Ben Pfaff wrote: > > > > I've had a number of queries from folks lately about our roadmap for > > > > LTS releases. It has, indeed, been a long time since we've had a > > > > long-term support release (the current LTS is 2.5). Usually, we've > > > > done LTS releases before some kind of big architectural change, etc., > > > > and so we've had no real internal pressure within the project to do it > > > > for a while. But it might be a good signal to the community to bring > > > > the LTS release forward. > > > > > > > > What does everyone think about making the next (2.11) release an LTS? > > > > > > > > > > I think it's a good idea. The current LTS is quite old now, especially for > > > the DPDK datapath. There is a new DPDK LTS coming out in November which > > > should be in for OVS 2.11, so it would be a nice combination for a user to > > > have LTS support for both. > > > > +1 > > > > With regards backporting support for LTS releases, I take it LTS takes > > priority over non LTS branches, that would be the only difference I would > > think? > > Yes, basically we should try harder to backport to LTS branches. > > > In fairness I think the community is pretty good as is for backporting > > bug fixes for all branches. > > We do a pretty good job of it most of the time. The main driver for LTS > releases has been big OVS internal changes that are likely to break > things. By doing an LTS release just before a version with those kinds > of changes, we gave our users something to confidently fall back on if > the next release was a little more unstable--not that we ever aim for > that, but it happens sometimes. We haven't had that kind of big change > recently, so we haven't had a natural impetus to release an LTS--and for > the same reason, it's been easy to backport most fixes because there > haven't been sweeping changes across the tree. What comes to mind is if OVN manages to split up from OVS soon. Wouldn't be easier if OVN, as a separated project, requires an OVS LTS version? If so, then 2.11 might not be the best one. -- Flavio ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] packet_type=legacy_l3 gre tunnel does not work
On 10/18/2018 10:28 PM, Yousong Zhou wrote:
On Fri, 19 Oct 2018 at 01:13, Gregory Rose wrote:
On 10/17/2018 6:01 AM, Yousong Zhou wrote:
I tried to use ip-over-gre with openvswitch 2.8.4, but no "ip proto
47" traffic can be seen with tcpdump. Later I added a WARN_ON_ONCE(1)
line just before the "goto drop" statement in ovs_vport_send() and it
was triggered right away thus pinpointed the problem.
It looks to me openvswitch linux kernel datapath always create
ARPHRD_IPGRE device and never set dev->type to ARPHRD_NONE. Please
correct me if this is not the case. The ovs-vswitchd.conf.db doc says
setting packet_type=legacy_l3 should work. I am trying to figure
what's the missing piece.
Openvswitch 2.8.4 depends on the built-in gre kernel module and it is true that
module will always set the device type to ARPHRD_IPGRE upon initial creation
but if the tunnel is set to a metadata type tunnel then the device type should
be reset to ARPHRD_NONE.
From ../net/ipv4/ip_gre.c:L1037
if (data[IFLA_GRE_COLLECT_METADATA]) {
struct ip_tunnel *t = netdev_priv(dev);
t->collect_md = true;
if (dev->type == ARPHRD_IPGRE)
dev->type = ARPHRD_NONE;
}
https://elixir.bootlin.com/linux/v4.6/source/net/ipv4/ip_gre.c#L1037
Perhaps that code is not being hit?
No, nl_attr *data[] was zeroed out in gretap_fb_dev_create().
And you are sure there is no subsequent call to ipgre_netlink_parms()?
t->collect_md = true was also set there. There was a patch [1] to
workaround this but it seems that the function is compat code and
kernel would rather not adding feature to it.
By the way, does someone know what is the meaning of _fb_ in
gretap_fb_dev_create()?
[1] [net-next,v12,9/9] openvswitch: use ipgre tunnel rather than
gretap tunnel, https://patchwork.ozlabs.org/patch/682916/
yousong
The _fb_ stands for either "fall back" or "fully backed" device (I've
heard both). It's necessary for namespace support IIRC.
- Greg
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] ovs-vswitchd high CPU usage after attaching new port
Hello, I migrated all instanced from “high cpu usage ovs” node to another node to avoid unexpected packet drop. When migration was finished, ovs-vswitchd was crashed suddenly. console logs when ovs-vswitchd was crashed /usr/local/bin/start-ovs: line 2:16 Segmentation fault (core dumped) /usr/sbin/ovs-vswitchd unix:/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info --mlockall --log-file=/var/log/kolla/openvswitch/ovs-vswitchd.log Please see attached file: ovs-vswitchd.log2.txt From: 우병열 [woobee] Sent: Friday, October 19, 2018 2:13 PM To: 'b...@openvswitch.org' Subject: ovs-vswitchd high CPU usage after attaching new port Hello, I want to report an issue that ovs-vswitchd high CPU usage after attaching new port. Please see following informations. The most important parts of your bug report are the following: * What you did that make the problem appear. * Neutron openvswitch agent added 4 ports on OVS Bridge. * What you expected to happen. * They were added successfully and nothing happened. * What actually happened. * Cpu usage became over 100% and ovs-vswitchd makes huge amount of logs. (please see attached file: ovs-vswitchd.log.txt) Please also include the following information: * The Open vSwitch version number (as output by ovs-vswitchd --version). * ovs-vswitchd (Open vSwitch) 2.10.0 * The Git commit number (as output by git rev-parse HEAD), if you built from a Git snapshot. * none * Any local patches or changes you have applied (if any). * none The following are also handy sometimes: * The kernel version on which Open vSwitch is running (from /proc/version) and the distribution and version number of your OS (e.g. “Centos 5.0”). * Linux version 4.15.0-34-generic (buildd@lgw01-amd64-047) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #37-Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018 * The contents of the vswitchd configuration database (usually /etc/openvswitch/conf.db). * Please see attached file: conf.db.txt * The output of ovs-dpctl show. * Please see attached file: ovs-dpctl-ofctl.txt * If you have Open vSwitch configured to connect to an OpenFlow controller, the output of ovs-ofctl show for each configured in the vswitchd configuration database. * Please see attached file: ovs-dpctl-ofctl.txt 2018-10-19T06:57:12.586Z|04727|poll_loop(handler140)|INFO|Dropped 1605325 log messages in last 6 seconds (most recently, 0 seconds ago) due to excessive rate 2018-10-19T06:57:12.586Z|04728|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (99% CPU usage) 2018-10-19T06:57:18.586Z|04729|poll_loop(handler140)|INFO|Dropped 1613830 log messages in last 6 seconds (most recently, 0 seconds ago) due to excessive rate 2018-10-19T06:57:18.586Z|04730|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (99% CPU usage) 2018-10-19T06:57:24.586Z|04731|poll_loop(handler140)|INFO|Dropped 159 log messages in last 6 seconds (most recently, 0 seconds ago) due to excessive rate 2018-10-19T06:57:24.586Z|04732|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (99% CPU usage) 2018-10-19T06:57:30.586Z|04733|poll_loop(handler140)|INFO|Dropped 1605681 log messages in last 6 seconds (most recently, 0 seconds ago) due to excessive rate 2018-10-19T06:57:30.586Z|04734|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (99% CPU usage) 2018-10-19T06:57:36.586Z|04735|poll_loop(handler140)|INFO|Dropped 1541293 log messages in last 6 seconds (most recently, 0 seconds ago) due to excessive rate 2018-10-19T06:57:36.586Z|04736|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (99% CPU usage) 2018-10-19T06:57:42.586Z|04737|poll_loop(handler140)|INFO|Dropped 1601181 log messages in last 6 seconds (most recently, 0 seconds ago) due to excessive rate 2018-10-19T06:57:42.586Z|04738|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (99% CPU usage) 2018-10-19T06:57:48.586Z|04739|poll_loop(handler140)|INFO|Dropped 1527392 log messages in last 6 seconds (most recently, 0 seconds ago) due to excessive rate 2018-10-19T06:57:48.586Z|04740|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (99% CPU usage) 2018-10-19T06:57:54.586Z|04741|poll_loop(handler140)|INFO|Dropped 1518579 log messages in last 6 seconds (most recently, 0 seconds ago) due to excessive rate 2018-10-19T06:57:54.586Z|04742|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd
[ovs-discuss] ovs-vswitchd high CPU usage after attaching new port
Hello, I want to report an issue that ovs-vswitchd high CPU usage after attaching new port. Please see following informations. The most important parts of your bug report are the following: * What you did that make the problem appear. * Neutron openvswitch agent added 4 ports on OVS Bridge. * What you expected to happen. * They were added successfully and nothing happened. * What actually happened. * Cpu usage became over 100% and ovs-vswitchd makes huge amount of logs. (please see attached file: ovs-vswitchd.log.txt) Please also include the following information: * The Open vSwitch version number (as output by ovs-vswitchd --version). * ovs-vswitchd (Open vSwitch) 2.10.0 * The Git commit number (as output by git rev-parse HEAD), if you built from a Git snapshot. * none * Any local patches or changes you have applied (if any). * none The following are also handy sometimes: * The kernel version on which Open vSwitch is running (from /proc/version) and the distribution and version number of your OS (e.g. “Centos 5.0”). * Linux version 4.15.0-34-generic (buildd@lgw01-amd64-047) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #37-Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018 * The contents of the vswitchd configuration database (usually /etc/openvswitch/conf.db). * Please see attached file: conf.db.txt * The output of ovs-dpctl show. * Please see attached file: ovs-dpctl-ofctl.txt * If you have Open vSwitch configured to connect to an OpenFlow controller, the output of ovs-ofctl show for each configured in the vswitchd configuration database. * Please see attached file: ovs-dpctl-ofctl.txt After launching a new instance, weired logs were generated. 2018-10-19T03:01:07.697Z|00665|bridge|INFO|bridge br-int: added interface qvo8234007f-49 on port 51 2018-10-19T03:01:15.534Z|00666|bridge|INFO|bridge br-tun: added interface vxlan-0aa80ca4 on port 52 2018-10-19T03:01:15.724Z|00667|bridge|INFO|bridge br-tun: added interface vxlan-0aa80ca1 on port 53 2018-10-19T03:01:15.855Z|00668|bridge|INFO|bridge br-tun: added interface vxlan-0aa80ca3 on port 54 2018-10-19T03:01:18.251Z|00669|connmgr|INFO|br-tun<->tcp:127.0.0.1:6633: 136 flow_mods in the 9 s starting 10 s ago (134 adds, 2 deletes) 2018-10-19T03:01:18.586Z|1|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (91% CPU usage) 2018-10-19T03:01:18.586Z|2|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (91% CPU usage) 2018-10-19T03:01:18.586Z|3|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (91% CPU usage) 2018-10-19T03:01:18.586Z|4|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (91% CPU usage) 2018-10-19T03:01:18.586Z|5|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (91% CPU usage) 2018-10-19T03:01:18.586Z|6|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (91% CPU usage) 2018-10-19T03:01:18.586Z|7|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (91% CPU usage) 2018-10-19T03:01:18.586Z|8|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (91% CPU usage) 2018-10-19T03:01:18.586Z|9|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (91% CPU usage) 2018-10-19T03:01:18.586Z|00010|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (91% CPU usage) 2018-10-19T03:01:24.586Z|00011|poll_loop(handler140)|INFO|Dropped 927778 log messages in last 6 seconds (most recently, 0 seconds ago) due to excessive rate 2018-10-19T03:01:24.586Z|00012|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (99% CPU usage) 2018-10-19T03:01:24.945Z|00670|connmgr|INFO|br-int<->tcp:127.0.0.1:6633: 15 flow_mods in the 2 s starting 10 s ago (12 adds, 3 deletes) 2018-10-19T03:01:30.586Z|00013|poll_loop(handler140)|INFO|Dropped 984156 log messages in last 6 seconds (most recently, 0 seconds ago) due to excessive rate 2018-10-19T03:01:30.586Z|00014|poll_loop(handler140)|INFO|wakeup due to [POLLIN] on fd 42 (unknown anon_inode:[eventpoll]) at ../lib/dpif-netlink.c:2786 (99% CPU usage) 2018-10-19T03:01:36.586Z|00015|poll_loop(handler140)|INFO|Dropped 933823 log messages in last 6 seconds (most recently, 0 seconds ago) due to
Re: [ovs-discuss] time for another LTS?
On Fri, Oct 19, 2018 at 11:48:07AM +, Stokes, Ian wrote: > > On 10/18/2018 10:46 PM, Ben Pfaff wrote: > > > I've had a number of queries from folks lately about our roadmap for > > > LTS releases. It has, indeed, been a long time since we've had a > > > long-term support release (the current LTS is 2.5). Usually, we've > > > done LTS releases before some kind of big architectural change, etc., > > > and so we've had no real internal pressure within the project to do it > > > for a while. But it might be a good signal to the community to bring > > > the LTS release forward. > > > > > > What does everyone think about making the next (2.11) release an LTS? > > > > > > > I think it's a good idea. The current LTS is quite old now, especially for > > the DPDK datapath. There is a new DPDK LTS coming out in November which > > should be in for OVS 2.11, so it would be a nice combination for a user to > > have LTS support for both. > > +1 > > With regards backporting support for LTS releases, I take it LTS takes > priority over non LTS branches, that would be the only difference I would > think? Yes, basically we should try harder to backport to LTS branches. > In fairness I think the community is pretty good as is for backporting > bug fixes for all branches. We do a pretty good job of it most of the time. The main driver for LTS releases has been big OVS internal changes that are likely to break things. By doing an LTS release just before a version with those kinds of changes, we gave our users something to confidently fall back on if the next release was a little more unstable--not that we ever aim for that, but it happens sometimes. We haven't had that kind of big change recently, so we haven't had a natural impetus to release an LTS--and for the same reason, it's been easy to backport most fixes because there haven't been sweeping changes across the tree. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] time for another LTS?
> On 10/18/2018 10:46 PM, Ben Pfaff wrote: > > I've had a number of queries from folks lately about our roadmap for > > LTS releases. It has, indeed, been a long time since we've had a > > long-term support release (the current LTS is 2.5). Usually, we've > > done LTS releases before some kind of big architectural change, etc., > > and so we've had no real internal pressure within the project to do it > > for a while. But it might be a good signal to the community to bring > > the LTS release forward. > > > > What does everyone think about making the next (2.11) release an LTS? > > > > I think it's a good idea. The current LTS is quite old now, especially for > the DPDK datapath. There is a new DPDK LTS coming out in November which > should be in for OVS 2.11, so it would be a nice combination for a user to > have LTS support for both. +1 With regards backporting support for LTS releases, I take it LTS takes priority over non LTS branches, that would be the only difference I would think? In fairness I think the community is pretty good as is for backporting bug fixes for all branches. Ian > > thanks, > Kevin. > > > Thanks, > > > > Ben. > > ___ > > 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 ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] time for another LTS?
On 10/18/2018 10:46 PM, Ben Pfaff wrote: > I've had a number of queries from folks lately about our roadmap for LTS > releases. It has, indeed, been a long time since we've had a long-term > support release (the current LTS is 2.5). Usually, we've done LTS > releases before some kind of big architectural change, etc., and so > we've had no real internal pressure within the project to do it for a > while. But it might be a good signal to the community to bring the LTS > release forward. > > What does everyone think about making the next (2.11) release an LTS? > I think it's a good idea. The current LTS is quite old now, especially for the DPDK datapath. There is a new DPDK LTS coming out in November which should be in for OVS 2.11, so it would be a nice combination for a user to have LTS support for both. thanks, Kevin. > Thanks, > > Ben. > ___ > 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
