On Wed, Oct 17, 2018 at 02:54:17PM +0200, Lorenzo Bianconi wrote:
> >
> > On Mon, Oct 15, 2018 at 11:31:55PM +0200, Lorenzo Bianconi wrote:
> > > >
> > > > On Fri, Oct 12, 2018 at 08:54:49AM -0700, Ben Pfaff wrote:
> > > > > On Fri, Oct 12, 2018 at 03:44:51PM +0300, Ilya Maximets wrote:
> > > > >
On Wed, Oct 17, 2018 at 7:45 PM Eelco Chaudron wrote:
>
>
> On 17 Oct 2018, at 14:03, nusid...@redhat.com wrote:
>
> > From: Numan Siddique
> >
> > We see the below trace when a port is added to a bridge and the
> > configured
> > controller is down
> >
> > 0x7fb002f8b207 in raise () from
On Wed, Oct 17, 2018 at 06:24:56PM +0200, Lorenzo Bianconi wrote:
> >
> > On Wed, Oct 17, 2018 at 02:54:17PM +0200, Lorenzo Bianconi wrote:
> > > >
> > > > On Mon, Oct 15, 2018 at 11:31:55PM +0200, Lorenzo Bianconi wrote:
> > > > > >
> > > > > > On Fri, Oct 12, 2018 at 08:54:49AM -0700, Ben Pfaff
On Tue, Oct 16, 2018 at 06:46:52PM -0400, Shahaji Bhosle via dev wrote:
> Just upgraded to 2.10 and running OvS with DPDK , I used to set MTU to 1900
> to accommodate VxLAN headers in 2.9 but not I cannot send packets bigger
> than 1518 bytes. Is this a known issue, I have not got chance to check
All of these seem fine to me.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On Wed, Oct 17, 2018 at 05:33:05PM +0530, nusid...@redhat.com wrote:
> From: Numan Siddique
>
> We see the below trace when a port is added to a bridge and the configured
> controller is down
>
> 0x7fb002f8b207 in raise () from /lib64/libc.so.6
> 0x7fb002f8c8f8 in abort () from
On 10.10.2018 19:22, Tiago Lam wrote:
> From: Mark Kavanagh
>
> There are numerous factors that must be considered when calculating
> the size of an mbuf:
> - the data portion of the mbuf must be sized in accordance With Rx
> buffer alignment (typically 1024B). So, for example, in order to
>
On Wed, Oct 17, 2018 at 10:01 PM Ben Pfaff wrote:
> On Wed, Oct 17, 2018 at 05:33:05PM +0530, nusid...@redhat.com wrote:
> > From: Numan Siddique
> >
> > We see the below trace when a port is added to a bridge and the
> configured
> > controller is down
> >
> > 0x7fb002f8b207 in raise ()
On Tue, Oct 16, 2018 at 07:47:16PM +0300, Ilya Maximets wrote:
> NO_OFFLOAD_API was removed while netdev classes initialization
> refactoring, but netdev-bsd still uses it. Instead of
> redefining it, I just refactored the BSD classes to be same
> as other netdevs.
>
> CC: Ben Pfaff
> Fixes:
>
> On Wed, Oct 17, 2018 at 02:54:17PM +0200, Lorenzo Bianconi wrote:
> > >
> > > On Mon, Oct 15, 2018 at 11:31:55PM +0200, Lorenzo Bianconi wrote:
> > > > >
> > > > > On Fri, Oct 12, 2018 at 08:54:49AM -0700, Ben Pfaff wrote:
> > > > > > On Fri, Oct 12, 2018 at 03:44:51PM +0300, Ilya Maximets
On Mon, Oct 15, 2018 at 04:12:19PM -0700, Justin Pettit wrote:
>
> > On Oct 10, 2018, at 1:35 PM, Ben Pfaff wrote:
> >
> > Since OVS added LACP support back in 2011, bonds have ignored the updelay
> > and downdelay values for bonds with configured LACP. The reason is not
> > clear, but at
Hello Daniel,
When I tried to configure vxlan routes I had mentioned I was seeing errors,
when I checked log files under /var/log/openvswitch there is no
information...
-rw-r- 1 root adm 0 Oct 17 06:25 ovs-vswitchd.log
-rw-r- 1 root adm 536 Oct 17 12:32 ovsdb-server.log
cat
I have a lucrative business proposal to discuss with you, please contact me on
my email:
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
This patch fixes the bug that all datapath and vport ops are returning
wrong values (OVS_FLOW_CMD_NEW or OVS_DP_CMD_NEW) in their replies.
This commit backports upstream net-next's commit 804fe108fc92e59
("openvswitch: Use correct reply values in datapath and vport ops").
Signed-off-by: Yifeng
On Wed, Oct 17, 2018 at 12:25:47PM -0700, Yifeng Sun wrote:
> This patch fixes the bug that all datapath and vport ops are returning
> wrong values (OVS_FLOW_CMD_NEW or OVS_DP_CMD_NEW) in their replies.
>
> This commit backports upstream net-next's commit 804fe108fc92e59
> ("openvswitch: Use
Thanks John,
I agree with you that this configuration is between vxlan0 and VF port and we
will see only decap packets from vxlan0.
So, I created another config on bridge br1 instead of br0 to mirror all traffic
between eth0.101 and tep0 port. How will this get mapped into the offloaded
Thanks Ben/Ilya,
Will give that a shot and update, I had to roll back to 2.9. But will
update. Thanks again and appreciate the quick reply, Shahaji
On Wed, Oct 17, 2018 at 11:35 AM Ben Pfaff wrote:
> On Tue, Oct 16, 2018 at 06:46:52PM -0400, Shahaji Bhosle via dev wrote:
> > Just upgraded to
---
Este correo electrónico ha sido comprobado en busca de virus por AVG.
http://www.avg.com
___
Hi Ankur,
Thanks for the detailed document! I always appreciate it when things are
planned out in great detail so we know exactly what to expect.
A general comment: there are places below where things like "figure 1"
and "figure OVN bridge deployment" are referenced, but we can't see
them.
Jumbo frames worked fine for me no so long ago on master branch.
Have you checked the log? What does it say?
Best regards, Ilya Maximets.
On 17.10.2018 01:46, Shahaji Bhosle wrote:
> Hi Ilya
> Just upgraded to 2.10 and running OvS with DPDK , I used to set MTU to 1900
> to accommodate VxLAN
Hi Mark,
Thanks a lot for the feedback.
Regarding the figures, i attached the PNGs (shows in my sent items), but looks
like they got filtered.
My bad on that, is there a location, where OVS community uploads images for
references.
Please bear with us, hopefully, we will be able to avoid some of
Hi Daniel,
When I try to ping I seeing following vxlan udp unreachable, when I try to
ping from host2-to-host1, basically packets entering br-phy and should be
delivered to br-int(on which vxlan is configured). Any configuration needed
to route packets from br-phy to br-int? What version of OVS
I am Peter Wong director of operations, Hong Kong and Shanghai Banking
Corporation Limited Hong Kong. I have a very confidential business
proposition involving transfer of $18.350.000.00 that will be of great
benefit for both of us. Reply for more details as regards this
transaction
Best Regards
From: Numan Siddique
We see the below trace when a port is added to a bridge and the configured
controller is down
0x7fb002f8b207 in raise () from /lib64/libc.so.6
0x7fb002f8c8f8 in abort () from /lib64/libc.so.6
0x7fb004953026 in ofputil_protocol_to_ofp_version () from
> When enabled with DPDK OvS deals with two types of packets, the ones
> coming from the mempool and the ones locally created by OvS - which are
> copied to mempool mbufs before output. In the latter, the space is
> allocated from the system, while in the former the mbufs are allocated
> from a
On Fri, Oct 12, 2018 at 9:52 PM Ben Pfaff wrote:
> On Fri, Aug 24, 2018 at 10:35:16AM -0700, Ben Pfaff wrote:
> > When the status of a port changes, ofproto calls into connmgr to notify
> > controllers. Sometimes, particular changes are only visible to
> controllers
> > running specific
On 17 Oct 2018, at 14:03, nusid...@redhat.com wrote:
From: Numan Siddique
We see the below trace when a port is added to a bridge and the
configured
controller is down
0x7fb002f8b207 in raise () from /lib64/libc.so.6
0x7fb002f8c8f8 in abort () from /lib64/libc.so.6
>
> On Mon, Oct 15, 2018 at 11:31:55PM +0200, Lorenzo Bianconi wrote:
> > >
> > > On Fri, Oct 12, 2018 at 08:54:49AM -0700, Ben Pfaff wrote:
> > > > On Fri, Oct 12, 2018 at 03:44:51PM +0300, Ilya Maximets wrote:
> > > > > > Hi,
> > > > > >
> > > > > > it seems that travis-ci is failing due to a
Wow, that was quick Numans,
Did you try the negative of the test? (removing your patch on the C side
and trying the test
to make sure it fails?)
On Wed, Oct 17, 2018 at 2:08 PM wrote:
> From: Numan Siddique
>
> We see the below trace when a port is added to a bridge and the configured
>
On Wed, Oct 17, 2018 at 6:27 PM Miguel Angel Ajo Pelayo
wrote:
> Wow, that was quick Numans,
>
> Did you try the negative of the test? (removing your patch on the C side
> and trying the test
> to make sure it fails?)
>
Yes. I actually started with the test to make sure it fails before working
Wow, proper TDD!
Is it possible to get this backported at least down to 2.10 ?
Acked-by: Miguel Angel Ajo
More context here: https://bugzilla.redhat.com/show_bug.cgi?id=1640045
On Wed, Oct 17, 2018 at 2:59 PM Numan Siddique wrote:
>
>
> On Wed, Oct 17, 2018 at 6:27 PM Miguel Angel Ajo
31 matches
Mail list logo