Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread One Thousand Gnomes
> These results for Toeplitz are not plausible. Given random input you > cannot expect any hash function to produce such uniform results. I > suspect either your input data is biased or how your applying the hash > is. > > When I run 64 random IPv4 3-tuples through Toeplitz and Jenkins I get >

Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread Eric Dumazet
On Wed, 2016-01-13 at 23:10 +, Haiyang Zhang wrote: > I have done a comparison of the Toeplitz v.s. Jenkins Hash algorithms, > and found that the Toeplitz provides much better distribution of the > connections into send-indirection-table entries. See the data below -- > showing how many

Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread Tom Herbert
> I have done a comparison of the Toeplitz v.s. Jenkins Hash algorithms, > and found that the Toeplitz provides much better distribution of the > connections into send-indirection-table entries. See the data below -- > showing how many TCP connections are distributed into each of the > sixteen

Re: [PATCH] staging: ion: make the pte default none PTE_RDONLY

2016-01-14 Thread kbuild test robot
Hi Chen, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.4 next-20160114] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Chen-Feng/staging-ion-make-the-pte

RE: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread Haiyang Zhang
> -Original Message- > From: Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Thursday, January 14, 2016 5:08 PM > To: Haiyang Zhang > Cc: Tom Herbert ; One Thousand Gnomes > ; David Miller

[PATCH] Staging: speakup: Fix getting port information

2016-01-14 Thread Samuel Thibault
Commit f79b0d9c223c ("staging: speakup: Fixed warning instead of ") broke the port information in the speakup driver: SERIAL_PORT_DFNS only gets defined if asm/serial.h is included, and no other header includes asm/serial.h. We here make sure serialio.c does get the arch-specific definition of

[PATCH] staging: ion : Donnot wakeup kswapd in ion system alloc

2016-01-14 Thread Chen Feng
Since ion alloc can be called by userspace,eg gralloc. When it is called frequently, the efficiency of kswapd is to low. And the reclaimed memory is too lower. In this way, the kswapd can use to much cpu resources. With 3.5GB DMA Zone and 0.5 Normal Zone. pgsteal_kswapd_dma 9364140

Re: [RFC PATCH v0] Add tw5864 driver

2016-01-14 Thread Andrey Utkin
On Mon, Jan 11, 2016 at 12:52 PM, Hans Verkuil wrote: > Did you also test with v4l2-compliance? Before I accept the driver I want to > see the > output of 'v4l2-compliance' and 'v4l2-compliance -s'. Basically there > shouldn't be > any failures. > > I did a quick scan over

[PATCH] staging: ion: make the pte default none PTE_RDONLY

2016-01-14 Thread Chen Feng
The page is already alloc at ion_alloc function, ion_mmap map the alloced pages to user-space. The default prot can be PTE_RDONLY. Take a look at here: set_pte_at() arch/arm64/include/asm: if (pte_dirty(pte) && pte_write(pte)) pte_val(pte) &= ~PTE_RDONLY;

Re: [PATCH] staging: ion: make the pte default none PTE_RDONLY

2016-01-14 Thread kbuild test robot
Hi Chen, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.4 next-20160114] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Chen-Feng/staging-ion-make-the-pte

[PATCH] Staging: xgifb: vgatypes.h: Coding style warning fix for block comments

2016-01-14 Thread YU Bo
This patch is to vgatypes.h file that fixes up following warnings reported by checkpatch.pl tool Signed-off-by: YU Bo --- drivers/staging/xgifb/vgatypes.h | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/staging/xgifb/vgatypes.h

Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread Tom Herbert
On Thu, Jan 14, 2016 at 10:35 AM, Haiyang Zhang wrote: > > >> -Original Message- >> From: Eric Dumazet [mailto:eric.duma...@gmail.com] >> Sent: Thursday, January 14, 2016 1:24 PM >> To: One Thousand Gnomes >> Cc: Tom Herbert

Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread Eric Dumazet
On Thu, 2016-01-14 at 17:53 +, One Thousand Gnomes wrote: > > These results for Toeplitz are not plausible. Given random input you > > cannot expect any hash function to produce such uniform results. I > > suspect either your input data is biased or how your applying the hash > > is. > > > >

Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread Tom Herbert
On Thu, Jan 14, 2016 at 11:15 AM, Haiyang Zhang wrote: > > >> -Original Message- >> From: Tom Herbert [mailto:t...@herbertland.com] >> Sent: Thursday, January 14, 2016 1:49 PM >> To: Haiyang Zhang >> Cc: Eric Dumazet

Re: [PATCH] Staging: speakup: Fix getting port information

2016-01-14 Thread Dan Carpenter
Great! Thanks. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: xgifb: vb_table.h: Coding style warning fix for block comments

2016-01-14 Thread YU Bo
This patch is to vb_table.h file that fixes up following warnings reported by checkpatch.pl: I) Block comments use * on subsequent lines. Signed-off-by: YU Bo --- drivers/staging/xgifb/vb_table.h |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH] Staging:lustre:lustre:obdclass:Remove return from void function

2016-01-14 Thread Bhumika Goyal
This patch removes the return statement at the end of a void function as it is not necessary.This was found by checkpatch.pl . Signed-off-by: Bhumika Goyal --- drivers/staging/lustre/lustre/obdclass/llog_swab.c | 2 -- 1 file changed, 2 deletions(-) diff --git

Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread Tom Herbert
On Thu, Jan 14, 2016 at 12:23 PM, Haiyang Zhang wrote: > > >> -Original Message- >> From: Tom Herbert [mailto:t...@herbertland.com] >> Sent: Thursday, January 14, 2016 2:41 PM >> To: Haiyang Zhang >> Cc: Eric Dumazet

RE: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread Haiyang Zhang
> -Original Message- > From: Tom Herbert [mailto:t...@herbertland.com] > Sent: Thursday, January 14, 2016 2:41 PM > To: Haiyang Zhang > Cc: Eric Dumazet ; One Thousand Gnomes > ; David Miller

RE: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread Haiyang Zhang
> -Original Message- > From: Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Thursday, January 14, 2016 1:24 PM > To: One Thousand Gnomes > Cc: Tom Herbert ; Haiyang Zhang > ; David Miller

RE: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread Haiyang Zhang
> -Original Message- > From: Tom Herbert [mailto:t...@herbertland.com] > Sent: Thursday, January 14, 2016 1:49 PM > To: Haiyang Zhang > Cc: Eric Dumazet ; One Thousand Gnomes > ; David Miller

Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread David Miller
From: Tom Herbert Date: Thu, 14 Jan 2016 13:44:24 -0800 > The fact that we can negatively affect the output of Toeplitz so > predictably is actually a liability and not a benefit. This sort of > thing can be the basis of a DOS attack and is why we kicked out XOR > hash in

Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-14 Thread Eric Dumazet
On Thu, 2016-01-14 at 20:23 +, Haiyang Zhang wrote: > > For non-random inputs, I used the port selection of iperf that increases > the port number by 2 for each connection. Only send-port numbers are > different, other values are the same. I also tested some other fixed > increment,