hi,
On Wed, Jun 3, 2015 at 3:36 PM, Ben Pfaff wrote:
> We have the following comment in ofproto-dpif-xlate.c:
>
> /* Prevent nested translation of OpenFlow groups.
> *
> * OpenFlow allows this restriction. We enforce this restriction only
> * because, with the
The original message was included as attachment
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Hi,
Hope this email finds you well!
Would you be interested in reaching out to " New Home Owners Email List
"with opt-in verified contact information?
We maintain contacts with complete details like Contact Name(First & Last
Name), Mailing Address, IP Address, List type, Source and
Non pmd threads have a core_id == UINT32_MAX, while queue ids used by
netdevs range from 0 to the number of CPUs. Therefore core ids cannot
be used directly to select a queue.
This commit introduces a simple mapping to fix the problem: pmd threads
continue using queues 0 to N (where N is the numb
I sent a v3 that uses an alternative mapping computed when the
pmd thread is created. I hope it's clearer
Thanks!
On 02/06/2015 18:33, "Flavio Leitner" wrote:
>On Fri, May 29, 2015 at 12:42:00PM +0100, Mark D. Gray wrote:
>> From: Daniele Di Proietto
>>
>> Non pmd threads have a core_id == UI
On Mon, 1 Jun 2015 16:27:32 +0200, Thomas Graf wrote:
> --- a/net/openvswitch/flow.h
> +++ b/net/openvswitch/flow.h
> @@ -45,6 +45,11 @@ struct sk_buff;
> #define TUN_METADATA_OPTS(flow_key, opt_len) \
> ((void *)((flow_key)->tun_opts + TUN_METADATA_OFFSET(opt_len)))
>
> +struct ovs_tunne
I am seeing the same kernel oops with a 3.10 kernel as well. I tried with a 4.0
kernel on EL7 and seems like the issue is fixed.
Do we have a bug id for this issue in the 4.0 dev tree? Also, can someone
confirm that the link Russell posted below is in fact the fix for this kernel
oops?
Thanks,
On Wed, Jun 03, 2015 at 03:55:16PM +0100, Daniele Di Proietto wrote:
> Non pmd threads have a core_id == UINT32_MAX, while queue ids used by
> netdevs range from 0 to the number of CPUs. Therefore core ids cannot
> be used directly to select a queue.
>
> This commit introduces a simple mapping to
Support IGMPv3 messages with multiple records. Make sure all IGMPv3
messages go through slow path, since they may carry multiple multicast
addresses, unlike IGMPv2.
Tests done:
* multiple addresses in IGMPv3 report are inserted in mdb;
* address is removed from IGMPv3 if record is INCLUDE_MODE;
*
I have some general questions about the vhost user feature which
aren't totally clear to me. I would greatly appreciate some
clarification, or pointers to documentation.
1) Since vhost-user is using standard Qemu interfaces, will it support
all of the features of the standard vhost implementation
On 06/03/15 at 05:29pm, Jiri Benc wrote:
> On Mon, 1 Jun 2015 16:27:32 +0200, Thomas Graf wrote:
> > --- a/net/openvswitch/flow.h
> > +++ b/net/openvswitch/flow.h
> > @@ -45,6 +45,11 @@ struct sk_buff;
> > #define TUN_METADATA_OPTS(flow_key, opt_len) \
> > ((void *)((flow_key)->tun_opts + TUN
Hi Ethan
>
> I have some general questions about the vhost user feature which aren't
> totally clear to me. I would greatly appreciate some clarification, or
> pointers
> to documentation.
Have you watched the presentation that Kevin and Maryam did at the conference
last year? It describes vho
Great thanks a lot for the detailed response, this is super helpful.
I'll take a look at the presentation and read the documentation.
Ethan
On Wed, Jun 3, 2015 at 3:09 PM, Gray, Mark D wrote:
> Hi Ethan
>
>>
>> I have some general questions about the vhost user feature which aren't
>> totally cl
Acked-by: Ethan Jackson
Merged.
Ethan
On Wed, Jun 3, 2015 at 10:45 AM, Flavio Leitner wrote:
> On Wed, Jun 03, 2015 at 03:55:16PM +0100, Daniele Di Proietto wrote:
>> Non pmd threads have a core_id == UINT32_MAX, while queue ids used by
>> netdevs range from 0 to the number of CPUs. Therefore
Mesmerising love will be presented by splendid cuties
http://cc4.co/ZPMOP
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Tue, Jun 2, 2015 at 8:58 AM, Jiri Benc wrote:
> On Mon, 1 Jun 2015 14:40:41 -0700, Jesse Gross wrote:
>> On Thu, May 14, 2015 at 11:10 AM, Jiri Benc wrote:
>> > diff --git a/include/uapi/linux/openvswitch.h
>> > b/include/uapi/linux/openvswitch.h
>> > index 4d26da40b01f..ba7ae3b05308 100644
>
On Tue, Jun 2, 2015 at 8:37 AM, Jiri Benc wrote:
> On Mon, 1 Jun 2015 14:22:48 -0700, Jesse Gross wrote:
>> On Thu, May 14, 2015 at 11:10 AM, Jiri Benc wrote:
>> > diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
>> > index 2af6ffbf2f2e..78e96a120120 100644
>> > --- a/net/openvswitch/
It should be once, from the host memory address space to the guestmemory
address space (and vice-versa in the other direction). I can not understand 'be
once'
In vhost, VM share *down* the memory to host, why host 'copy the pkts from the
host memory address space to the guest memory address s
The original message was received at Thu, 4 Jun 2015 13:29:05 +0800
from redhat.com [54.128.151.202]
- The following addresses had permanent fatal errors -
- Transcript of session follows -
while talking to openvswitch.org.:
>>> MAIL From:swhit...@redhat.com
<<< 501 swhit...@re
OVS datapath has check which prevents the installation of flow
that matches VLAN TCI but does not have exact match for VLAN_CFI
bit. However, the ovs userspace does not enforce it, so OpenFlow
flow like "vlan_tci=0x000a/0x0fff,action=output:local" can be added
to ovs. Subsequently, the generated
I can reproduce the same issue Ronald report on master ovs.
This patch will break the following tests on master:
testsuite: 329 340 350 385 389 390 391 failed
My understanding is that since we require the exact match for VLAN_CFI in
kernel. We should also enforce it in userspace so that no Open
21 matches
Mail list logo
