On 06/13/2018 12:36 PM, Yidong Ren wrote:
> From: Yidong Ren
>
> This patch implements following ethtool stats fields for netvsc:
> cpu_tx/rx_packets/bytes
> cpu_vf_tx/rx_packets/bytes
...
>
> + pcpu_sum = alloc_percpu(struct netvsc_ethtool_pcpu_stats);
> + netvsc_get_pcpu_stats(dev
On Mon, 2018-03-05 at 20:19 +0100, Horatiu Vultur wrote:
> Fix partial warnings of checkpatch.pl for ipx_route.c
>
> Signed-off-by: Horatiu Vultur
> ---
> drivers/staging/ipx/ipx_route.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
Please take a look at drivers/staging/ipx/
On Mon, 2017-11-13 at 11:32 -0800, Joe Perches wrote:
> On Mon, 2017-11-13 at 09:11 -0800, Stephen Hemminger wrote:
> > Support for Decnet has been orphaned for some time.
> > In the interest of reducing the potential bug surface and pre-holiday
> > cleaning, move the decnet protocol into staging f
On Tue, 2017-10-31 at 14:42 +0100, Vitaly Kuznetsov wrote:
> RCU_INIT_POINTER() is not suitable here as it doesn't give us ordering
> guarantees (see the comment in rcupdate.h). This is also not a hotpath.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> drivers/net/hyperv/netvsc.c | 2 +-
> 1 file c
ve all usage of last_rx and switch three drivers (sky2, atp and
> smc91c92_cs) which actually read and write it to use their own private
> copy in netdev_priv.
>
> Compile-tested with allyesconfig and allmodconfig on x86 and arm.
SGTM, thanks a lot for doing this Tobias.
z
> but it seems there is no good excuse for Toeplitz to stay.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
Acked-by: Eric Dumazet
Thanks !
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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, Toepl
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.
> >
> > W
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 TCP
On Thu, 2016-01-07 at 10:33 +0100, Vitaly Kuznetsov wrote:
> Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add
> VLAN ID to flow_keys")) introduced a performance regression in netvsc
> driver. Is problem is, however, not the above mentioned commit but the
> fact that netvsc_
On Wed, 2015-12-16 at 19:20 +, Haiyang Zhang wrote:
> > -Original Message-
> > From: Eric Dumazet [mailto:eric.duma...@gmail.com]
> > Sent: Wednesday, December 16, 2015 12:08 PM
> >
> > This looks very very wrong to me.
> >
> > How many tim
On Wed, 2015-12-16 at 10:03 -0800, Haiyang Zhang wrote:
> To avoid performance overhead when using skb_flow_dissect_flow_keys(),
> we switch to the simple parsers to get the IP and port numbers.
>
> Performance comparison: throughput (Gbps):
> Number of connections, before patch, after patch
> 1
On Mon, 2015-11-09 at 20:23 +, Simon Xiao wrote:
> Thanks Eric to provide the data. I am looping Tom (as I am looking into his
> recent patches) and Olaf (from Suse).
>
> So, if I understand it correctly, you are running netperf with single
> TCP connection, and you got ~26Gbps initially and
On Sat, 2015-11-07 at 11:35 -0800, Eric Dumazet wrote:
> On Fri, 2015-11-06 at 14:30 -0700, David Ahern wrote:
> > On 11/6/15 2:18 PM, Simon Xiao wrote:
> > > The .config file used to build linux-next kernel is attached to this mail.
> >
> > Thanks.
> >
&g
On Fri, 2015-11-06 at 14:30 -0700, David Ahern wrote:
> On 11/6/15 2:18 PM, Simon Xiao wrote:
> > The .config file used to build linux-next kernel is attached to this mail.
>
> Thanks.
>
> Failed to notice this on the first response; my brain filled in. Why
> linux-next tree? Can you try net-nex
On Wed, 2015-05-06 at 18:28 +, KY Srinivasan wrote:
> Ah! I too was wondering how we could get into this situation. The condition
> you mention
> is already handled in the lower level - if the attempt to put the last packet
> on vmbus were to
> fail because the ring is full, we will notify t
On Wed, 2015-05-06 at 11:20 -0700, K. Y. Srinivasan wrote:
> Based on the information given to this driver (via the xmit_more skb flag),
> we can defer signaling the host if more packets are on the way. This will help
> make the host more efficient since it can potentially process a larger batch
>
On Thu, 2015-04-30 at 16:29 -0700, K. Y. Srinivasan wrote:
> Based on the information given to this driver (via the xmit_more skb flag),
> we can defer signaling the host if more packets are on the way. This will help
> make the host more efficient since it can potentially process a larger batch
>
On Sun, 2014-11-23 at 01:51 +0100, SF Markus Elfring wrote:
> > This has nothing to do with me asking you to frame your patches
> > against the correct tree.
>
> I imagine than someone other can also pick up this update suggestion
> (a simple change of two lines) quicker before I might try another
On Fri, 2014-04-25 at 17:43 -0700, Stephen Hemminger wrote:
> On Fri, 25 Apr 2014 11:45:14 -0700
> "K. Y. Srinivasan" wrote:
>
> > @@ -474,6 +477,9 @@ static int netvsc_start_xmit(struct sk_buff *skb,
> > struct net_device *net)
> > csum_info = (struct ndis_tcp_ip_checksum_info *)((void *)pp
20 matches
Mail list logo
