½µív_ësA)ìoãJ8ÆNuHÕÉ÷''Z¹[}u·Hæ²O
.wM´EÏ¡·ßô]O³ÁIG¼-5,;«¹ì.Ú©À/g±äN)
a3ÉiÁ½#ðÓ1)µÒÖçäÂÖïEêÅRr¹ DZ°}ê3
qÒf
uJ,íYb{°C¡_¿ô˽«;¹ê¡çIÀ
ÐÑß,?¿5gM¾8ɳÀ.ò P¼f¸?h[v½Ø¸È.[¹÷ÆÓ-Û¬yHrWÃeæýukjV}
Ïv4ø
¬/w³±éøô0yÉ·eéãëÌh¯Y¼ýQ0ܽËeãV¢ýêÅÐëÕ-Ú üIfÁñßÃMlícW⼪Ëu
On Fri, Feb 27, 2015 at 7:13 PM, Chris Dunlop ch...@onthe.net.au wrote:
On Fri, Feb 27, 2015 at 11:08:21AM -0800, Pravin Shelar wrote:
On Thu, Feb 26, 2015 at 9:13 PM, Chris Dunlop ch...@onthe.net.au
wrote:
Hi,
Me too on Simon's BUG() described below (apologies for the top post).
On Fri, Feb 27, 2015 at 6:49 PM, Chris Dunlop ch...@onthe.net.au wrote:
On Fri, Feb 27, 2015 at 06:06:25PM -0500, Xu (Simon) Chen wrote:
On Friday, February 27, 2015, Chris Dunlop ch...@onthe.net.au wrote:
Simon, are you able to try your test running direct hypervisor
to hypervisor?
On Fri, 27 Feb 2015, Christoph Lameter wrote:
+/*
+ * Construct gfp mask to allocate from a specific node but do not invoke
reclaim
+ * or warn about failures.
+ */
We should be triggering reclaim from slab allocations. Why would we not do
this?
Otherwise we will be going
On Fri, Feb 27, 2015 at 08:31:46PM -0500, Xu (Simon) Chen wrote:
On Fri, Feb 27, 2015 at 6:49 PM, Chris Dunlop ch...@onthe.net.au wrote:
On Fri, Feb 27, 2015 at 06:06:25PM -0500, Xu (Simon) Chen wrote:
On Friday, February 27, 2015, Chris Dunlop ch...@onthe.net.au wrote:
Simon, are you
µÆ ó ÔñjväcÊ©ûÅpÆáð
zåXþ
Ð
©åÚêHumÇqáqnwr(ÞxDeȳ[z
:1ÖµIUYÒìÏÌ»wZ´î»ª#z«aôôù-ø;°5#8ëHÆ·ë
bòÍVæp¦iîë3g²©«?
^/E#W
4̸ç!¥½Z¬a»NáÈÛ]4r¸¡¡T«6jïuO¨e4IJ(íþÂúþ$°dúÇ,éÙZɽDPN#ÏÄQøÙoy˺»XÙã/Ь¬in:¬
p$)µ
õ8Mµx9¡b§ø82ÊÐN|
hê®ktÙJÒRÁfí?
W¬T°÷,ó¶ì³¨´u
On Fri, Feb 27, 2015 at 08:30:42PM -0500, Xu (Simon) Chen wrote:
On Fri, Feb 27, 2015 at 6:14 PM, Pravin Shelar pshe...@nicira.com wrote:
So it looks like vhost is generating shared skb. Can you try same test
on latest upstream kernel?
I don't know whether it's vhost, as for me the VM
On Fri, Feb 27, 2015 at 08:33:13PM -0500, Xu (Simon) Chen wrote:
On Fri, Feb 27, 2015 at 7:13 PM, Chris Dunlop ch...@onthe.net.au wrote:
On Fri, Feb 27, 2015 at 11:08:21AM -0800, Pravin Shelar wrote:
Can you reproduce this bug on hypervisor to hypervisor
test without any VMs?
The
From: Ben Pfaff [mailto:b...@nicira.com]
Sent: Friday, February 27, 2015 12:17 AM
Hi Mark. Thanks for this review and your other one on this commit.
For most of your comments, the answer is that I should add some more
documentation, or some more clarifications to the existing
This commit adds a new test for hash_bytes128() using single 128-bit
word. The test shows that there is no collision in all 17 consecutive
bits checks, which indicates the hash function is good.
Signed-off-by: Alex Wang al...@nicira.com
---
tests/test-hash.c | 100
Forgot to ack
Acked-by: Gray, Mark D mark.d.g...@intel.com
-Original Message-
From: Ben Pfaff [mailto:b...@nicira.com]
Sent: Friday, February 27, 2015 6:21 AM
To: dev@openvswitch.org
Cc: Ben Pfaff; Gray, Mark D
Subject: [PATCH] ovn-architecture: Describe integration bridge setup on
From: Ben Pfaff [mailto:b...@nicira.com]
Sent: Friday, February 27, 2015 6:54 AM
On Thu, Feb 26, 2015 at 05:11:54PM +, Gray, Mark D wrote:
From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Ben
Pfaff
Sent: Friday, February 20, 2015 7:20 AM
To: dev@openvswitch.org
Cc:
Thx for review applied to master,
On Fri, Feb 27, 2015 at 8:03 AM, Ben Pfaff b...@nicira.com wrote:
On Thu, Feb 26, 2015 at 10:40:53AM -0800, Alex Wang wrote:
This commit refines the check_256byte_hash() function by moving
some checks to outer loop.
Signed-off-by: Alex Wang
snip
What do you mean by OVN integration bridge here? Is it a bridge
instantiated on the OVS instance running on the host?
Yes.
I assume it's like br-int but I will check the patch you reference below.
Also, will the underlying setup of OVS be the same that is currently
set up
Thx for the review, applied to master
As Joe suggested, I'll add another test for testing the hash_bytes128 using
single 128-bit word. And find the magic number n such that there is no
collision in all n-bit consecutive runs.
Thanks,
Alex Wang,
On Fri, Feb 27, 2015 at 8:04 AM, Ben Pfaff
-Original Message-
From: Ben Pfaff [mailto:b...@nicira.com]
Sent: Friday, February 27, 2015 6:21 AM
The term integration bridge was being used without explanation.
Reported-by: Gray, Mark D mark.d.g...@intel.com
Signed-off-by: Ben Pfaff b...@nicira.com
---
Looks good, minor comments inline.
On 27 February 2015 at 09:33, Alex Wang al...@nicira.com wrote:
This commit adds a new test for hash_bytes128() using single 128-bit
word. The test shows that there is no collision in all 17 consecutive
bits checks, which indicates the hash function is good.
On Mon, Feb 23, 2015 at 10:25:01PM +0100, Russell Bryant wrote:
On 02/21/2015 03:51 AM, Kyle Mestery wrote:
On Fri, Feb 20, 2015 at 7:15 PM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:
On 02/20/2015 06:46 PM, Ben Pfaff wrote:
* Not yet scoped:
On Thu, Feb 26, 2015 at 10:40:53AM -0800, Alex Wang wrote:
This commit refines the check_256byte_hash() function by moving
some checks to outer loop.
Signed-off-by: Alex Wang al...@nicira.com
Acked-by: Ben Pfaff b...@nicira.com
___
dev mailing list
On Thu, Feb 26, 2015 at 10:40:54AM -0800, Alex Wang wrote:
The original test fails on big-endian system due to the hash function
performing not as well when input is uint32_t. In reality, users should
only use hash_bytes128() to hash words larger than 128 bits (e.g. struct
flow). Besides, we
On Thu, Feb 26, 2015 at 9:13 PM, Chris Dunlop ch...@onthe.net.au wrote:
Hi,
Me too on Simon's BUG() described below (apologies for the top post).
Basically:
[ 7318.409796] kernel BUG at net/core/skbuff.c:1041!
...
[ 7318.591562] RIP: 0010:[813eb634] [813eb634]
On Tue, Feb 24, 2015 at 5:33 AM, Chetan Bali chetan.b...@aricent.com wrote:
Hi,
I am configuring gre-port in my ovs bridge, for establishing gre-tunnel
between 2 machines. I am trying to parse the tunnelling key params sent by
OVS while adding flow, when it sets action as
A large number of 'failed to flow_del' error messages are being logged in
OpenStack deployments running the Ubuntu Trusty release with the 3.13 kernel.
This was fixed upstream in the datapath dkms module as well as the 3.16 kernel.
Commit 4a46b24e is the fix for this issue, and is in
On 26 February 2015 at 14:43, Pravin Shelar pshe...@nicira.com wrote:
On Thu, Feb 19, 2015 at 11:13 AM, Joe Stringer joestrin...@nicira.com wrote:
This patch series backports the UFID changes from the Linux 3.19 tree to the
OVS tree.
Joe Stringer (5):
datapath: Refactor
Please line wrap your email to ~80 columns, it was totally unreadable
in my plain text email client.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Fri, 27 Feb 2015, Vlastimil Babka wrote:
Oh, right. I missed the new trigger. My sanity and career is saved!
Haha.
Well, no... the flags are still a mess. Aren't GFP_TRANSHUGE | __GFP_THISNODE
allocations still problematic after this patch and 2/2? Those do include
__GFP_WAIT (unless
On Fri, Feb 27, 2015 at 06:06:25PM -0500, Xu (Simon) Chen wrote:
On Friday, February 27, 2015, Chris Dunlop ch...@onthe.net.au wrote:
Simon, are you able to try your test running direct hypervisor
to hypervisor?
Nope... I have only seen this between VMs. After repeated tests, it has
got
On Fri, Feb 27, 2015 at 11:08:21AM -0800, Pravin Shelar wrote:
On Thu, Feb 26, 2015 at 9:13 PM, Chris Dunlop ch...@onthe.net.au wrote:
Hi,
Me too on Simon's BUG() described below (apologies for the top post).
Basically:
[ 7318.409796] kernel BUG at net/core/skbuff.c:1041!
...
[
Commit 077fcf116c8c (mm/thp: allocate transparent hugepages on local
node) restructured alloc_hugepage_vma() with the intent of only
allocating transparent hugepages locally when there was not an effective
interleave mempolicy.
alloc_pages_exact_node() does not limit the allocation to the single
Nothing calls __cpuset_node_allowed() with __GFP_THISNODE set anymore, so
remove the obscure comment about it and its special-case exception.
Signed-off-by: David Rientjes rient...@google.com
---
kernel/cpuset.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff
On 02/27/2015 11:03 PM, David Rientjes wrote:
With both
patches they won't bail out and __GFP_NO_KSWAPD will prevent most of the
stuff
described above, including clearing ALLOC_CPUSET.
Yeah, ALLOC_CPUSET is never cleared for thp allocations because atomic ==
false for thp, regardless of
On Fri, 27 Feb 2015, Vlastimil Babka wrote:
Do you see any issues with either patch 1/2 or patch 2/2 besides the
s/GFP_TRANSHUGE/GFP_THISNODE/ that is necessary on the changelog?
Well, my point is, what if the node we are explicitly trying to allocate
hugepage on, is in fact not allowed
On Fri, Feb 27, 2015 at 3:06 PM, Xu (Simon) Chen xche...@gmail.com wrote:
On Friday, February 27, 2015, Chris Dunlop ch...@onthe.net.au wrote:
On Fri, Feb 27, 2015 at 11:08:21AM -0800, Pravin Shelar wrote:
On Thu, Feb 26, 2015 at 9:13 PM, Chris Dunlop ch...@onthe.net.au
wrote:
Hi,
Coucou
Je m'appelle Claire marie 29 ans j'habite à Lyon et je désire correspondre avec
un homme pour construire ensemble une relation sérieuse et mener ensemble notre
petit bout de chemin, célibataire depuis 7 mois, j'ai finalement décidée de
m'investir à nouveau dans la recherche de l'âme
Thx a lot for the review, I finally setup my first qemu powerpc debian
and run the test there~... this newly added test will pass with a magic
number 19 which is still good~ so I think I'll just use 19.
Thanks,
Alex Wang,
On Fri, Feb 27, 2015 at 10:09 AM, Joe Stringer joestrin...@nicira.com
On Fri, Feb 27, 2015 at 6:14 PM, Pravin Shelar pshe...@nicira.com wrote:
On Fri, Feb 27, 2015 at 3:06 PM, Xu (Simon) Chen xche...@gmail.com
wrote:
On Friday, February 27, 2015, Chris Dunlop ch...@onthe.net.au wrote:
On Fri, Feb 27, 2015 at 11:08:21AM -0800, Pravin Shelar wrote:
On
This commit adds a new test for hash_bytes128() using single 128-bit
word. The test shows that there is no collision in all 19 consecutive
bits checks, which indicates the hash function is good.
Signed-off-by: Alex Wang al...@nicira.com
---
PATCH-V2:
- test it on big-endian system, and adopt
This commit makes check_word_hash() run to finish even when there
is a failure during the run. The test will still fail due to the
output check in AT_CHECK. And developers can benefit from having
all failed hashes instead of only the first one.
Signed-off-by: Alex Wang al...@nicira.com
---
NOTE: this is not about __GFP_THISNODE, this is only about GFP_THISNODE.
GFP_THISNODE is a secret combination of gfp bits that have different
behavior than expected. It is a combination of __GFP_THISNODE,
__GFP_NORETRY, and __GFP_NOWARN and is special-cased in the page allocator
slowpath to fail
On Fri, 27 Feb 2015, David Rientjes wrote:
+/*
+ * Construct gfp mask to allocate from a specific node but do not invoke
reclaim
+ * or warn about failures.
+ */
We should be triggering reclaim from slab allocations. Why would we not do
this?
Otherwise we will be going uselessly off node
On 27.2.2015 23:31, David Rientjes wrote:
On Fri, 27 Feb 2015, Vlastimil Babka wrote:
Do you see any issues with either patch 1/2 or patch 2/2 besides the
s/GFP_TRANSHUGE/GFP_THISNODE/ that is necessary on the changelog?
Well, my point is, what if the node we are explicitly trying to allocate
On Fri, Feb 27, 2015 at 11:08:21AM -0800, Pravin Shelar wrote:
On Thu, Feb 26, 2015 at 9:13 PM, Chris Dunlop ch...@onthe.net.au wrote:
Hi,
Me too on Simon's BUG() described below (apologies for the top post).
Basically:
[ 7318.409796] kernel BUG at net/core/skbuff.c:1041!
...
[
42 matches
Mail list logo
