On Mon, Dec 10, 2018 at 11:44:01PM +, Tobias Hofmann -T (tohofman - AAP3
INC at Cisco) wrote:
> Hi Ben,
>
> Thanks for the quick reply.
>
> Command that I'm using: ovs-vsctl remove bridge test-br datapath_type netdev
> Output message: ovs-vsctl: "remove" operation would put 0
Hi Ben,
Thanks for the quick reply.
Command that I'm using: ovs-vsctl remove bridge test-br datapath_type netdev
Output message:ovs-vsctl: "remove" operation would put 0 values in column
datapath_type of table Bridge but the minimum number is 1
I still think that the empty string is
Yes sir. That fixes it - vswitchd no longer crashes.
Thanks,
On Tue, Dec 11, 2018 at 12:31 PM Ben Pfaff wrote:
> Here's a more specific patch that, if my hypothesis is correct, would
> solve the issue.
>
> diff --git a/ofproto/connmgr.c b/ofproto/connmgr.c
> index 7c0f16b321f1..ebee5817710e
Here's a more specific patch that, if my hypothesis is correct, would
solve the issue.
diff --git a/ofproto/connmgr.c b/ofproto/connmgr.c
index 7c0f16b321f1..ebee5817710e 100644
--- a/ofproto/connmgr.c
+++ b/ofproto/connmgr.c
@@ -1493,7 +1493,7 @@ ofconn_receives_async_msg(const struct ofconn
On Mon, Dec 10, 2018 at 10:01:48PM +, Tobias Hofmann -T (tohofman - AAP3
INC at Cisco) via discuss wrote:
> Hi,
>
> I noticed that the property datapath_type of a freshly created bridge is by
> default empty. In order to support DPDK, I have to set the datapath_type to
> netdev.
>
> Now
Hi,
I noticed that the property datapath_type of a freshly created bridge is by
default empty. In order to support DPDK, I have to set the datapath_type to
netdev.
Now when I want to disable DPDK, I try to remove the datapath_type again which
fails saying that datapath_type cannot be empty.
I tried this patch on top of 2.10.1.
vswitchd now crashes with status 0 so no coredump when I run the original
repro scenario (we can reproduce the problem on two different machines).
2018-12-10T21:33:30.934Z|2|daemon_unix(monitor)|INFO|pid 4829 died,
exit status 0, exiting
A bad pointer
On Tue, Nov 27, 2018 at 03:21:01PM -0500, Eric Garver wrote:
> On Mon, Nov 19, 2018 at 07:32:46AM -0800, Sim Paul wrote:
> > >
> > >
> > > > I am still trying to understand the test case behavior that i pasted in
> > > my
> > > > previous email.
> > > > In my first test case when vlan-limit=1, the
Probably, this is a different issue. My guess is that the connection in
question doesn't have an OpenFlow protocol at the moment. We've dealt
with problems like this before, see e.g. commit 903f6c4f8a9b ("connmgr:
Fix vswitchd abort when a port is added and the controller is down").
Either that
The problem happens with OpenFlow 1.0 and 1.3. I am not aware of any
possibility that Ryu could be configured to use an unsupported version, and
even if so I would imagine OVS would reject the connection at the Hello
stage.
On Tue, Dec 11, 2018, 09:16 Flavio Leitner
> Looks like you're using an
On Mon, Dec 10, 2018 at 07:20:03PM +, Sachin Sharma wrote:
> Hi Flavio,
>
> Thanks for your reply!
> The packet counter in the flow-stats (using dump-flows) is increasing very
> rapidly.
> I have just sent 1 packet. If I dump traffic through tcpdump, there are
> lots of packets appearing. I
Looks like you're using an unsupported OpenFlow protocol:
https://github.com/openvswitch/ovs/blob/5f361a2a320717c46289fc30d65a186f2f5d3ba0/lib/ofp-protocol.c#L123
I see that you are configuring a controller in OVS and you are
running Ryu, maybe it's using the wrong protocol version?
fbl
On
Hi Olivier,
Thanks for reaching out. I looked over netcx some time ago and pondered on the
benefits.
Unfortunately this is still not in its final form and AFAIK no other vendor
switched to it, so digging into it for the time being is not a priority.
However if you want to contribute any ideas
Hi Flavio,
Thanks for your reply!
The packet counter in the flow-stats (using dump-flows) is increasing very
rapidly.
I have just sent 1 packet. If I dump traffic through tcpdump, there are
lots of packets appearing. I think that the same packet is looping back.
Kind Regards,
Sachin.
On Mon,
Certainly:
2018-12-04 21:23:59 josh #1 0x7f870edf9801 in __GI_abort () at
abort.c:79
2018-12-04 21:23:59 josh #2 0x5634f368e0a8 in
ofputil_protocol_to_ofp_version (protocol=) at
lib/ofp-protocol.c:123
2018-12-04 21:23:59 josh #3 0x5634f36890ae in
ofputil_encode_port_status
On Fri, Dec 07, 2018 at 12:24:02PM +, Sachin Sharma wrote:
> Hi all,
> I have created a setup of two nodes : VMa-VMb. I ran ovs in VMb and
> added the following flow entry in vmb: ovs-ofctl add-flow vmb in_port=1,
> actions=in_port.
> I now sent a ping message from VMa towards VMb. As I
On Wed, Dec 05, 2018 at 08:01:45PM +0530, Numan Siddique wrote:
> On Wed, Dec 5, 2018 at 4:27 PM Ramzah Rehman wrote:
>
> > I am trying to bind an interface eth0 to vfio driver. I have made sure
> > iommu is enabled in grub and kernel. I have loaded the module vfio-pci. Ran
> > following
On Wed, Dec 05, 2018 at 12:11:28PM +1300, Josh Bailey via discuss wrote:
> Hello OVS colleagues,
>
> vswitchd appears to crash handling a port add/mod. Please see following to
> reproduce.
>
> Run two Ryu OF controllers:
>
> $ ryu-manager --ofp-tcp-listen-port 6653 --ofp-listen-host 127.0.0.1
On Fri, Nov 23, 2018 at 03:25:02PM +0800, 梁永正 wrote:
> Hi
>
> I have met a problem.In function reconfigure_datapath, port->dynamic_txqs =
> netdev_n_txq(port->netdev) < wanted_txqs; seems always be zero.
>
> If I want to enable multiqueue of the vhost-user device.Does the pmd-threads
> must
Hello all,
I've started to look at the OVS-DPDK vxlan tunneling feature as well as the
different examples in openvswitch.org.
I have a few questions/notes on which I would be glad to have your opinion and
thoughts.
1. When configuring port as type vxlan the remote_ip option is a must.
It
20 matches
Mail list logo
