* Re: [PATCH 05/11] Removing dead CASSINI_NAPI
From: David Miller @ 2010-07-14 20:36 UTC (permalink / raw)
To: siccegge
Cc: adobriyan, jpirko, joe, shemminger, netdev, linux-kernel,
vamos-dev
In-Reply-To: <582064a9d6be5cc6f620884ed5120ceb21fdbb12.1279110895.git.siccegge@cs.fau.de>
From: Christoph Egger <siccegge@cs.fau.de>
Date: Wed, 14 Jul 2010 14:40:59 +0200
> CASSINI_NAPI doesn't exist in Kconfig, therefore removing all
> references for it from the source code.
>
> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
Applied.
^ permalink raw reply
* [PATCH] Net: ethernet: pe2.c: fix EXPORT_SYMBOL macro code style issue
From: Chihau Chau @ 2010-07-14 20:24 UTC (permalink / raw)
To: davem; +Cc: tj, netdev, linux-kernel, Chihau Chau
From: Chihau Chau <chihau@gmail.com>
This patch fix a code style issuei, if a function is exported, the
EXPORT_SYMBOL macro for it should follow immediately after the closing
function brace line.
Signed-off-by: Chihau Chau <chihau@gmail.com>
---
net/ethernet/pe2.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/ethernet/pe2.c b/net/ethernet/pe2.c
index eb00796..85d574a 100644
--- a/net/ethernet/pe2.c
+++ b/net/ethernet/pe2.c
@@ -28,11 +28,10 @@ struct datalink_proto *make_EII_client(void)
return proto;
}
+EXPORT_SYMBOL(make_EII_client);
void destroy_EII_client(struct datalink_proto *dl)
{
kfree(dl);
}
-
EXPORT_SYMBOL(destroy_EII_client);
-EXPORT_SYMBOL(make_EII_client);
--
1.5.6.3
^ permalink raw reply related
* [PATCH] Net: ethernet: eth: fix some code style issues
From: Chihau Chau @ 2010-07-14 20:22 UTC (permalink / raw)
To: davem; +Cc: eric.dumazet, opurdila, netdev, linux-devel, mitov, Chihau Chau
From: Chihau Chau <chihau@gmail.com>
This fixes to include <linux/uaccess.h> instead <asm/uaccess.h> and some
code style issues like space before close parenthesis and space before
tabs.
Signed-off-by: Chihau Chau <chihau@gmail.com>
---
net/ethernet/eth.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 61ec032..25ccce0 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -58,7 +58,7 @@
#include <net/ipv6.h>
#include <net/ip.h>
#include <net/dsa.h>
-#include <asm/uaccess.h>
+#include <linux/uaccess.h>
#include <asm/system.h>
__setup("ether=", netdev_boot_setup);
@@ -180,7 +180,8 @@ __be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev)
* seems to set IFF_PROMISC.
*/
- else if (1 /*dev->flags&IFF_PROMISC */ ) {
+ /*dev->flags&IFF_PROMISC */
+ else if (1) {
if (unlikely(compare_ether_addr_64bits(eth->h_dest, dev->dev_addr)))
skb->pkt_type = PACKET_OTHERHOST;
}
@@ -338,7 +339,7 @@ void ether_setup(struct net_device *dev)
{
dev->header_ops = ð_header_ops;
dev->type = ARPHRD_ETHER;
- dev->hard_header_len = ETH_HLEN;
+ dev->hard_header_len = ETH_HLEN;
dev->mtu = ETH_DATA_LEN;
dev->addr_len = ETH_ALEN;
dev->tx_queue_len = 1000; /* Ethernet wants good queues */
--
1.5.6.3
^ permalink raw reply related
* Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Greg KH @ 2010-07-14 20:20 UTC (permalink / raw)
To: Pankaj Thakkar
Cc: Shreyas Bhatewara, Christoph Hellwig, Stephen Hemminger,
pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <F1354E79A137A24CBA60059AA65CB1B802A34EEB67@EXCH-MBX-2.vmware.com>
On Wed, Jul 14, 2010 at 10:18:22AM -0700, Pankaj Thakkar wrote:
> The plugin is guest agnostic and hence we did not want to rely on any
> kernel provided functions. The plugin uses only the interface provided
> by the shell.
Really? vmxnet3_plugin.c is no supposed to use any kernel-provided
functions at all? Then why have it in the kernel at all? Seriously,
why?
> The assumption is that since the plugin is really simple and straight
> forward (all the control/init complexity lies in the PF driver in the
> hypervisor) we should be able to get by for most of the things and for
> things like memcpy/memset the plugin can write simple functions like
> this.
If it's so simple, then why does it need to be separate? Why not just
put it in your driver as-is to handle the ring-buffer logic (as that's
all it looks to be doing), and then you don't need any plugin code at
all?
It looks like you are linking this file into your "main" driver module,
so I fail to see any type of separation at all happening with this
patch.
Or am I totally missing something here?
thanks,
greg k-h
^ permalink raw reply
* Re: Raise initial congestion window size / speedup slow start?
From: Rick Jones @ 2010-07-14 20:17 UTC (permalink / raw)
To: Ed W; +Cc: David Miller, davidsen, linux-kernel, netdev
In-Reply-To: <4C3E0684.5060409@wildgooses.com>
Ed W wrote:
>
> Just checking the basics here because I don't think this is a bug so
> much as a, less common installation that differs from the "normal" case.
>
> - When we create a tcp connection we always start with tcp slow start
> - This sets the congestion window to effectively 4 packets?
> - This applies in both directions?
Any TCP sender in some degree of compliance with the RFCs on the topic will
employ slow-start.
Linux adds the auto-tuning of the receiver's advertised window. It will start
at a small size, and then grow it as it sees fit.
> - Remote sender responds to my hypothetical http request with the first
> 4 packets of data
> - We need to wait one RTT for the ack to come back and now we can send
> the next 8 packets,
> - Wait for the next ack and at 16 packets we are now moving at a
> sensible fraction of the bandwidth delay product?
There may be some wrinkles depending on how many ACKs the reciever generates
(LRO being enabled and such) and how the ACKs get counted.
> So just to be clear:
> - We don't seem to have any user-space tuning knobs to influence this
> right now?
> - In this age of short attention spans, a couple of extra seconds
> between clicking something and it responding is worth optimising (IMHO)
There is an effort under way, lead by some folks at Google and including some
others, to get the RFC's enhanced in support of the concept of larger initial
congestion windows. Some of the discussion may be in the "tcpm" mailing list
(assuming I've not gotten my mailing lists confused). There may be some
previous discussion of that work in the netdev archives as well.
rick jones
> - I think I need to take this to netdev, but anyone else with any ideas
> happy to hear them?
>
> Thanks
>
> Ed W
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: e1000e: receives no packets after resume (2.6.35-rc3-00262-g984bc96)
From: Tantilov, Emil S @ 2010-07-14 19:22 UTC (permalink / raw)
To: Nico Schottelius, Kirsher, Jeffrey T
Cc: e1000-devel@lists.sourceforge.net, netdev, Allan, Bruce W, LKML
In-Reply-To: <20100703081732.GA24281@schottelius.org>
Nico Schottelius wrote:
> Hey Jeff,
>
> Jeff Kirsher [Fri, Jul 02, 2010 at 02:47:26PM -0700]:
>> On Fri, Jul 2, 2010 at 00:28, Nico Schottelius
>> <nico-linux-20100702@schottelius.org> wrote:
>> [...]
>> Adding the Networking Kernel mailing list (netdev) and Intel Linux
>> LAN Driver mailing list (e1000-patches)...
>>
>> Would it be possible to get more information about the system/setup?
>>
>> For example, can you provide the following information:
>> - full lspci output (lspci -vvv)
>> - ethtool -i ethX
>> - dmesg - after loading the driver and configuring the
>> interfaces
>> - kernel config
>
> Attached!
>
> Cheers,
>
> Nico
<snip>
>[ 12.228826] e1000e 0000:00:19.0: irq 44 for MSI/MSI-X
>[ 12.279610] e1000e 0000:00:19.0: irq 44 for MSI/MSI-X
>[ 12.280200] ADDRCONF(NETDEV_UP): eth0: link is not ready
>[ 18.282340] e1000e 0000:00:19.0: eth0: Error reading PHY register
Note the error from your dmesg log. This is a known issue and we are working on it.
In meantime you should be able to w/a it by reloading the driver.
Thanks,
Emil
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 03/11] Removing dead CASSINI_QGE_DEBUG
From: David Miller @ 2010-07-14 19:18 UTC (permalink / raw)
To: siccegge; +Cc: netdev, linux-kernel, vamos-dev
In-Reply-To: <f44daaa9771dd77f0d351aac327436ebad005fa3.1279110894.git.siccegge@cs.fau.de>
From: Christoph Egger <siccegge@cs.fau.de>
Date: Wed, 14 Jul 2010 14:39:58 +0200
> CASSINI_QGE_DEBUG doesn't exist in Kconfig, therefore removing all
> references for it from the source code.
>
> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 02/11] Removing dead {AR,WAVE}LAN
From: David Miller @ 2010-07-14 19:17 UTC (permalink / raw)
To: siccegge; +Cc: netdev, linux-kernel, vamos-dev
In-Reply-To: <3da4fcf94d2364af32c44a8442b756c8b525f6fc.1279110894.git.siccegge@cs.fau.de>
From: Christoph Egger <siccegge@cs.fau.de>
Date: Wed, 14 Jul 2010 14:39:52 +0200
> {AR,WAVE}LAN doesn't exist in Kconfig, therefore removing all
> references for it from the source code.
>
> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
Applied to net-next-2.6
^ permalink raw reply
* Re: Raise initial congestion window size / speedup slow start?
From: Stephen Hemminger @ 2010-07-14 19:10 UTC (permalink / raw)
To: Ed W; +Cc: David Miller, davidsen, linux-kernel, netdev
In-Reply-To: <4C3E0684.5060409@wildgooses.com>
On Wed, 14 Jul 2010 19:48:36 +0100
Ed W <lists@wildgooses.com> wrote:
> On 14/07/2010 19:15, David Miller wrote:
> > From: Bill Davidsen<davidsen@tmr.com>
> > Date: Wed, 14 Jul 2010 11:21:15 -0400
> >
> >
> >> You may have to go into /proc/sys/net/core and crank up the
> >> rmem_* settings, depending on your distribution.
> >>
> > You should never, ever, have to touch the various networking sysctl
> > values to get good performance in any normal setup. If you do, it's a
> > bug, report it so we can fix it.
> >
>
> Just checking the basics here because I don't think this is a bug so
> much as a, less common installation that differs from the "normal" case.
>
> - When we create a tcp connection we always start with tcp slow start
> - This sets the congestion window to effectively 4 packets?
> - This applies in both directions?
> - Remote sender responds to my hypothetical http request with the first
> 4 packets of data
> - We need to wait one RTT for the ack to come back and now we can send
> the next 8 packets,
> - Wait for the next ack and at 16 packets we are now moving at a
> sensible fraction of the bandwidth delay product?
>
> So just to be clear:
> - We don't seem to have any user-space tuning knobs to influence this
> right now?
> - In this age of short attention spans, a couple of extra seconds
> between clicking something and it responding is worth optimising (IMHO)
> - I think I need to take this to netdev, but anyone else with any ideas
> happy to hear them?
>
> Thanks
>
> Ed W
TCP slow start is required by the RFC. It is there to prevent a TCP congestion
collapse. The HTTP problem is exacerbated by things beyond the user's control:
1. stupid server software that dribbles out data and doesn't used the full
payload of the packets
2. web pages with data from multiple sources (ads especially), each of which
requires a new connection
3. pages with huge graphics.
Most of this is because of sites that haven't figured out that somebody on a phone
across the globl might not have the same RTT and bandwidth that the developer on a
local network that created them. Changing the initial cwnd isn't going to fix it.
^ permalink raw reply
* Re: Raise initial congestion window size / speedup slow start?
From: Ed W @ 2010-07-14 18:48 UTC (permalink / raw)
To: David Miller; +Cc: davidsen, linux-kernel, netdev
In-Reply-To: <20100714.111553.104052157.davem@davemloft.net>
On 14/07/2010 19:15, David Miller wrote:
> From: Bill Davidsen<davidsen@tmr.com>
> Date: Wed, 14 Jul 2010 11:21:15 -0400
>
>
>> You may have to go into /proc/sys/net/core and crank up the
>> rmem_* settings, depending on your distribution.
>>
> You should never, ever, have to touch the various networking sysctl
> values to get good performance in any normal setup. If you do, it's a
> bug, report it so we can fix it.
>
Just checking the basics here because I don't think this is a bug so
much as a, less common installation that differs from the "normal" case.
- When we create a tcp connection we always start with tcp slow start
- This sets the congestion window to effectively 4 packets?
- This applies in both directions?
- Remote sender responds to my hypothetical http request with the first
4 packets of data
- We need to wait one RTT for the ack to come back and now we can send
the next 8 packets,
- Wait for the next ack and at 16 packets we are now moving at a
sensible fraction of the bandwidth delay product?
So just to be clear:
- We don't seem to have any user-space tuning knobs to influence this
right now?
- In this age of short attention spans, a couple of extra seconds
between clicking something and it responding is worth optimising (IMHO)
- I think I need to take this to netdev, but anyone else with any ideas
happy to hear them?
Thanks
Ed W
^ permalink raw reply
* Re: [RFC PATCH]: Fix a warning in the niu driver
From: Prarit Bhargava @ 2010-07-14 18:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100714.112800.189702548.davem@davemloft.net>
On 07/14/2010 02:28 PM, David Miller wrote:
> From: Prarit Bhargava <prarit@redhat.com>
> Date: Wed, 14 Jul 2010 09:18:31 -0400
>
>
>> Dave, would it be acceptable if I then wrapped link in
>> uninitialized_var() to get rid of the warning I'm trying to resolve? It
>> seems that your patch then checks for a valid page value so it should be
>> okay.
>>
> If the patch I posted doesn't fix your warning, the compiler is broken.
>
>
Oops -- my bad. I think I fat fingered something. Your patch
absolutely fixes the warning. Thanks Dave.
P.
^ permalink raw reply
* Re: [RFC PATCH]: Fix a warning in the niu driver
From: David Miller @ 2010-07-14 18:28 UTC (permalink / raw)
To: prarit; +Cc: netdev
In-Reply-To: <4C3DB927.2060106@redhat.com>
From: Prarit Bhargava <prarit@redhat.com>
Date: Wed, 14 Jul 2010 09:18:31 -0400
> Dave, would it be acceptable if I then wrapped link in
> uninitialized_var() to get rid of the warning I'm trying to resolve? It
> seems that your patch then checks for a valid page value so it should be
> okay.
If the patch I posted doesn't fix your warning, the compiler is broken.
Any code path that would not initialize the variable, hits the BUG()
therefore making return from the function completely unreachable,
therefore the uses of the initialized variable are completely unreachable.
I'm not adding workarounds for compiler warning bugs. They aren't real
bugs, and such efforts tend to _add_ bugs to the tree rather than fix
real problems.
^ permalink raw reply
* Re: Raise initial congestion window size / speedup slow start?
From: David Miller @ 2010-07-14 18:15 UTC (permalink / raw)
To: davidsen; +Cc: lists, linux-kernel, netdev
In-Reply-To: <4C3DD5EB.9070908@tmr.com>
From: Bill Davidsen <davidsen@tmr.com>
Date: Wed, 14 Jul 2010 11:21:15 -0400
> You may have to go into /proc/sys/net/core and crank up the
> rmem_* settings, depending on your distribution.
You should never, ever, have to touch the various networking sysctl
values to get good performance in any normal setup. If you do, it's a
bug, report it so we can fix it.
I cringe every time someone says to do this, so please do me a favor
and don't spread this further. :-)
For one thing, TCP dynamically adjusts the socket buffer sizes based
upon the behavior of traffic on the connection.
And the TCP memory limit sysctls (not the core socket ones) are sized
based upon available memory. They are there to protect you from
situations such as having so much memory dedicated to socket buffers
that there is none left to do other things effectively. It's a
protective limit, rather than a setting meant to increase or improve
performance. So like the others, leave these alone too.
^ permalink raw reply
* [PATCH 06/11] tulip: formatting of pointers in printk()
From: Kulikov Vasiliy @ 2010-07-14 18:03 UTC (permalink / raw)
To: kernel-janitors
Cc: Grant Grundler, Kyle McMartin, David S. Miller, Joe Perches,
Jiri Pirko, Stephen Hemminger, Eric Dumazet, netdev, linux-kernel
Use %p instead of %08x in printk().
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/tulip/winbond-840.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tulip/winbond-840.c b/drivers/net/tulip/winbond-840.c
index 608b279..66d41cf 100644
--- a/drivers/net/tulip/winbond-840.c
+++ b/drivers/net/tulip/winbond-840.c
@@ -1514,12 +1514,12 @@ static int netdev_close(struct net_device *dev)
if (debug > 2) {
int i;
- printk(KERN_DEBUG" Tx ring at %08x:\n", (int)np->tx_ring);
+ printk(KERN_DEBUG" Tx ring at %p:\n", np->tx_ring);
for (i = 0; i < TX_RING_SIZE; i++)
printk(KERN_DEBUG " #%d desc. %04x %04x %08x\n",
i, np->tx_ring[i].length,
np->tx_ring[i].status, np->tx_ring[i].buffer1);
- printk(KERN_DEBUG " Rx ring %08x:\n", (int)np->rx_ring);
+ printk(KERN_DEBUG " Rx ring %p:\n", np->rx_ring);
for (i = 0; i < RX_RING_SIZE; i++) {
printk(KERN_DEBUG " #%d desc. %04x %04x %08x\n",
i, np->rx_ring[i].length,
--
1.7.0.4
^ permalink raw reply related
* Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Jeremy Fitzhardinge @ 2010-07-14 18:03 UTC (permalink / raw)
To: David Miller
Cc: pthakkar, pv-drivers, greg, linux-kernel, virtualization, hch,
netdev, shemminger
In-Reply-To: <20100714.105423.226778756.davem@davemloft.net>
On 07/14/2010 10:54 AM, David Miller wrote:
> And doing what you're doing is foolish on so many levels. One more
> duplication of code, one more place for unnecessary bugs to live, one
> more place that might need optimizations and thus require duplication
> of even more work people have done over the years.
>
Not to mention calling a function "MoveMemory" when it doesn't do a
memmove is just cruel.
J
^ permalink raw reply
* [PATCH 05/11] tulip: formatting of pointers in printk()
From: Kulikov Vasiliy @ 2010-07-14 18:02 UTC (permalink / raw)
To: kernel-janitors
Cc: Grant Grundler, Kyle McMartin, David S. Miller, Joe Perches,
Jiri Pirko, Ben Hutchings, Grant Likely, netdev, linux-kernel,
devicetree-discuss
Use %p instead of %08x in printk().
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/tulip/tulip_core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index 03e96b9..14e5312 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -596,10 +596,10 @@ static void tulip_tx_timeout(struct net_device *dev)
pr_cont(" %02x", buf[j]);
pr_cont(" j=%d\n", j);
}
- printk(KERN_DEBUG " Rx ring %08x: ", (int)tp->rx_ring);
+ printk(KERN_DEBUG " Rx ring %p: ", tp->rx_ring);
for (i = 0; i < RX_RING_SIZE; i++)
pr_cont(" %08x", (unsigned int)tp->rx_ring[i].status);
- printk(KERN_DEBUG " Tx ring %08x: ", (int)tp->tx_ring);
+ printk(KERN_DEBUG " Tx ring %p: ", tp->tx_ring);
for (i = 0; i < TX_RING_SIZE; i++)
pr_cont(" %08x", (unsigned int)tp->tx_ring[i].status);
pr_cont("\n");
--
1.7.0.4
^ permalink raw reply related
* Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: David Miller @ 2010-07-14 17:54 UTC (permalink / raw)
To: pthakkar
Cc: greg, sbhatewara, hch, shemminger, pv-drivers, netdev,
linux-kernel, virtualization
In-Reply-To: <F1354E79A137A24CBA60059AA65CB1B802A34EEB67@EXCH-MBX-2.vmware.com>
From: Pankaj Thakkar <pthakkar@vmware.com>
Date: Wed, 14 Jul 2010 10:18:22 -0700
> The plugin is guest agnostic and hence we did not want to rely on
> any kernel provided functions.
While I disagree entirely with this kind of approach, even that
doesn't justify what you're doing here.
memcpy() and memset() are on a much more fundamental ground than
"kernel provided functions". They had better be available no matter
where you build this thing.
And doing what you're doing is foolish on so many levels. One more
duplication of code, one more place for unnecessary bugs to live, one
more place that might need optimizations and thus require duplication
of even more work people have done over the years.
^ permalink raw reply
* Re: [PATCHv3 NEXT 0/5]qlcnic: aer state
From: David Miller @ 2010-07-14 17:31 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <1279089215-23231-1-git-send-email-amit.salecha@qlogic.com>
From: amit.salecha@qlogic.com
Date: Tue, 13 Jul 2010 23:33:30 -0700
> I was in under impression that using space after tab is illegal.
What's undesirable is using spaces instead of tabs for fresh
code-block lines like:
foo();
Also, it is undesirable to have spaces mixed into the middle of a
sequence of tab characters. The spaces, when used to align expression
continuation lines or lists of function arguments, should be at the
end.
So in cases like:
if (foo &&
bar)
The second line should be a tab character, then the spaces to make
the alignment happen.
^ permalink raw reply
* Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Shreyas Bhatewara @ 2010-07-14 17:19 UTC (permalink / raw)
To: Greg KH
Cc: Christoph Hellwig, Stephen Hemminger, Pankaj Thakkar,
pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <20100714094952.GA16209@kroah.com>
On Wed, 14 Jul 2010, Greg KH wrote:
> On Mon, Jul 12, 2010 at 08:06:28PM -0700, Shreyas Bhatewara wrote:
> > drivers/net/vmxnet3/vmxnet3_drv.c | 1845
> > +++++++++++++++++++--------------
>
> Your patch is line-wrapped and can not be applied :(
>
> Care to fix your email client?
>
> One thing just jumped out at me when glancing at this:
>
> > +static INLINE void
> > +MoveMemory(void *dst,
> > + void *src,
> > + size_t length)
> > +{
> > + size_t i;
> > + for (i = 0; i < length; ++i)
> > + ((u8 *)dst)[i] = ((u8 *)src)[i];
> > +}
> > +
> > +static INLINE void
> > +ZeroMemory(void *memory,
> > + size_t length)
> > +{
> > + size_t i;
> > + for (i = 0; i < length; ++i)
> > + ((u8 *)memory)[i] = 0;
> > +}
>
> Is there some reason that our in-kernel functions that do this type of
> logic are not working for you to require you to reimplement this?
>
> thanks,
>
> greg k-h
>
Greg,
Thanks for pointing out. I will fix both these issues and repost the patch.
->Shreyas
^ permalink raw reply
* RE: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Pankaj Thakkar @ 2010-07-14 17:18 UTC (permalink / raw)
To: Greg KH, Shreyas Bhatewara
Cc: pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, Christoph Hellwig,
Stephen Hemminger
In-Reply-To: <20100714094952.GA16209@kroah.com>
The plugin is guest agnostic and hence we did not want to rely on any kernel provided functions. The plugin uses only the interface provided by the shell. The assumption is that since the plugin is really simple and straight forward (all the control/init complexity lies in the PF driver in the hypervisor) we should be able to get by for most of the things and for things like memcpy/memset the plugin can write simple functions like this.
-p
________________________________________
From: Greg KH [greg@kroah.com]
Sent: Wednesday, July 14, 2010 2:49 AM
To: Shreyas Bhatewara
Cc: Christoph Hellwig; Stephen Hemminger; Pankaj Thakkar; pv-drivers@vmware.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; virtualization@lists.linux-foundation.org
Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
Is there some reason that our in-kernel functions that do this type of
logic are not working for you to require you to reimplement this?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] netfilter: xtables: userspace notification target
From: Pablo Neira Ayuso @ 2010-07-14 16:34 UTC (permalink / raw)
To: Luciano Coelho
Cc: ext Patrick McHardy, Changli Gao, Samuel Ortiz, David S. Miller,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
In-Reply-To: <1279110169.20985.41.camel@chilepepper>
Hi Luciano,
On 14/07/10 14:22, Luciano Coelho wrote:
> On Wed, 2010-07-14 at 13:48 +0200, ext Patrick McHardy wrote:
>> If you're using connection tracking, you can use conntrack marks
>> to avoid sending more than a single message:
>>
>> iptables ... -m connmark --mark 0x1/0x1 -j RETURN
>> iptables ... -j NFLOG ...
>> iptables ... -j CONNMARK --set-mark 0x1/0x1
>
> Cool, thanks.
>
> It seems that there are lots of possibilities to get this to work, but
> this is starting to get quite complex. I would still prefer having the
> NFNOTIF module included, since we would be able to do what we want in a
> very simple way. It's also probably much more efficient that using
> several rules, which would increase the CPU usage considerably (in our
> device we are already reaching the limit of a reasonable CPU resource
> usage with high throughput WLAN connections).
>
> While I agree that it is possible to achieve the NFNOTIF functionality
> with existing modules, I still think there is a "niche" for such module,
> because it is very simple, has a very clear purpose and would make the
> ruleset simpler and more efficient.
>
> Does this make any sense?
I don't think that the NFNOTIF infrastructure fulfill the policy for
inclusion. It seems to me like something quite specific for your needs.
It is simple, yes, but we already have this feature into the kernel. I
don't think that this will reduce CPU usage considerably with regards to
the NFLOG way.
I would still prefer adding the once-per-matching notification feature
to NFLOG than these extra lines in the kernel, Patrick?
^ permalink raw reply
* RE: Splice status
From: Ofer Heifetz @ 2010-07-14 15:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Changli Gao, Jens Axboe, netdev@vger.kernel.org
In-Reply-To: <1279030308.2634.349.camel@edumazet-laptop>
Hi,
The strange thing happens when I configure it to use 256K using fcntl, I see that it uses splice with 1460 bytes, I tried making it smaller but no change.
Any clue why I get smaller pipe though trying to resize it to 256K?
BTW I changed the kernel to 2.6.35_rc5.
-Ofer
-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: Tuesday, July 13, 2010 5:12 PM
To: Ofer Heifetz
Cc: Changli Gao; Jens Axboe; netdev@vger.kernel.org
Subject: RE: Splice status
Le mardi 13 juillet 2010 à 14:41 +0300, Ofer Heifetz a écrit :
> Hi,
>
> I wanted to let you know that I have been testing Samba splice on Marvell 6282 SoC on 2.6.35_rc3 and noticed that it gave worst performance than not using it and also noticed that on re-writing file the iowait is high.
>
> iometer using 2G file (file is created before test)
>
> Splice write cpu% iow%
> -----------------------
> No 58 98 0
> Yes 14 100 48
>
> iozone using 2G file (file created during test)
>
> Splice write cpu% iow% re-write cpu% iow%
> -------------------------------------------
> No 35 85 4 58.2 70 0
> Yes 33 85 4 15.7 100 58
>
> Any clue why splice introduces a high iowait?
> I noticed samba uses up to 16K per splice syscall, changing the samba to try more did not help, so I guess it is a kernel limitation.
>
splice(socket -> pipe) provides partial buffers (depending on the MTU)
With typical MTU=1500 and tcp timestamps, each network frame contains
1448 bytes of payload, partially filling one page (of 4096 bytes)
When doing the splice(pipe -> file), kernel has to coalesce partial
data, but amount of written data per syscall() is small (about 20
Kbytes)
Without splice(), the write() syscall provides more data, and vfs
overhead is smaller as buffer size is a power of two.
Samba uses a 128 KBytes TRANSFER_BUF_SIZE in its default_sys_recvfile()
implementation, it easily outperforms splice() implementation.
You could try extending pipe size (fcntl(fd, F_SETPIPE_SZ, 256)), maybe
it will be a bit better. (and ask 256*4096 bytes to splice())
I tried this and got about 256Kbytes per splice() call...
# perf report
# Events: 13K
#
# Overhead Command Shared Object Symbol
# ........ .............. ................. ......
#
8.69% splice-fromnet [kernel.kallsyms] [k] memcpy
3.82% splice-fromnet [kernel.kallsyms] [k] kunmap_atomic
3.51% splice-fromnet [kernel.kallsyms] [k] __block_prepare_write
2.79% splice-fromnet [kernel.kallsyms] [k] __skb_splice_bits
2.58% splice-fromnet [kernel.kallsyms] [k] ext3_mark_iloc_dirty
2.45% splice-fromnet [kernel.kallsyms] [k] do_get_write_access
2.04% splice-fromnet [kernel.kallsyms] [k] __find_get_block
1.89% splice-fromnet [kernel.kallsyms] [k] _raw_spin_lock
1.83% splice-fromnet [kernel.kallsyms] [k] journal_add_journal_head
1.46% splice-fromnet [bnx2x] [k] bnx2x_rx_int
1.46% splice-fromnet [kernel.kallsyms] [k] kfree
1.42% splice-fromnet [kernel.kallsyms] [k] journal_put_journal_head
1.29% splice-fromnet [kernel.kallsyms] [k] __ext3_get_inode_loc
1.26% splice-fromnet [kernel.kallsyms] [k] journal_dirty_metadata
1.25% splice-fromnet [kernel.kallsyms] [k] page_address
1.20% splice-fromnet [kernel.kallsyms] [k] journal_cancel_revoke
1.15% splice-fromnet [kernel.kallsyms] [k] tcp_read_sock
1.09% splice-fromnet [kernel.kallsyms] [k] unlock_buffer
1.09% splice-fromnet [kernel.kallsyms] [k] pipe_to_file
1.05% splice-fromnet [kernel.kallsyms] [k] radix_tree_lookup_element
1.04% splice-fromnet [kernel.kallsyms] [k] kmap_atomic_prot
1.04% splice-fromnet [kernel.kallsyms] [k] kmem_cache_free
1.03% splice-fromnet [kernel.kallsyms] [k] kmem_cache_alloc
1.01% splice-fromnet [bnx2x] [k] bnx2x_poll
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Felix Fietkau @ 2010-07-14 14:44 UTC (permalink / raw)
To: John W. Linville
Cc: Ivo Van Doorn, Christoph Egger, Gertjan van Wingerde,
Bartlomiej Zolnierkiewicz, Helmut Schaa,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
vamos-dev-DSeRVwK2yFR7NQr57o4jwX20dTPRyWU8FLXUG6abMr4,
Luis Correia
In-Reply-To: <20100714131527.GB2352-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On 2010-07-14 3:15 PM, John W. Linville wrote:
> On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
>> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge-n+aIp8eCc/CzQB+pC5nmwQ@public.gmane.org> wrote:
>> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
>> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
>> >> so all Code depending on that can't ever be selected and, if there's
>> >> no plan to add these options, should be cleaned up
>> >>
>> >> Signed-off-by: Christoph Egger <siccegge-n+aIp8eCc/CzQB+pC5nmwQ@public.gmane.org>
>> >
>> > NAK,
>> >
>> > this is not dead code, it is needed for the Ralink System-on-Chip
>> > Platform devices.
>> >
>> > While I can't fix Kconfig errors and the current KConfig file may be
>> > wrong, this code cannot and will not be deleted.
>>
>> When the config option was introduced, the config options RALINK_RT288X and
>> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
>>
>> But since testing is done on SoC boards by Helmut and Felix, I assume the code
>> isn't dead but actually in use.
>
> Perhaps Helmut and Felix can send us the missing code?
The missing code is a MIPS platform port, which is currently being
maintained in OpenWrt, but is not ready for upstream submission yet.
I'm not working on this code at the moment, but I think it will be
submitted once it's ready.
- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Bartlomiej Zolnierkiewicz @ 2010-07-14 14:14 UTC (permalink / raw)
To: Ivo Van Doorn
Cc: Egger, Gertjan van Wingerde, John W. Linville, Felix Fietkau,
Helmut Schaa, linux-wireless, users, netdev, linux-kernel,
vamos-dev, Luis Correia
In-Reply-To: <AANLkTikCeDys9e1EnE9GdiJtDRcbqW3gzvsmjzvB_yDs@mail.gmail.com>
On Wednesday 14 July 2010 02:52:14 pm Ivo Van Doorn wrote:
> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com> wrote:
> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de> wrote:
> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> >> so all Code depending on that can't ever be selected and, if there's
> >> no plan to add these options, should be cleaned up
> >>
> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
> >
> > NAK,
> >
> > this is not dead code, it is needed for the Ralink System-on-Chip
> > Platform devices.
> >
> > While I can't fix Kconfig errors and the current KConfig file may be
> > wrong, this code cannot and will not be deleted.
>
> When the config option was introduced, the config options RALINK_RT288X and
> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
>
> But since testing is done on SoC boards by Helmut and Felix, I assume the code
> isn't dead but actually in use.
>
> Ivo
I fully agree with Luis and Ivo that the proposed patch is invalid and
shouldn't be applied (the "code cannot and will not be deleted" anyway)..
[ Under "The New Normal" rules the code doesn't even have to work to be
merged and/or stay in the kernel so 9 months of code not being used by
any real user doesn't matter a tiny bit.. ]
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* [PATCH 5/5] Remove REDWOOD_5 and REDWOOD_6 config options and conditional code
From: Christian Dietrich @ 2010-07-14 14:05 UTC (permalink / raw)
To: Josh Boyer, Matt Porter, Benjamin Herrenschmidt, Paul Mackerras,
Solomon
Cc: vamos-dev
In-Reply-To: <c3c850bed3f5714f1efcfad24ad4f8bfcb6b5b54.1279116162.git.qy03fugy@stud.informatik.uni-erlangen.de>
The config options for REDWOOD_[56] were commented out in the powerpc
Kconfig. The ifdefs referencing this options therefore are dead and all
references to this can be removed (Also dependencies in other KConfig
files).
Signed-off-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de>
---
arch/powerpc/platforms/40x/Kconfig | 16 -------------
drivers/mtd/maps/Kconfig | 2 +-
drivers/mtd/maps/redwood.c | 43 ------------------------------------
drivers/net/Kconfig | 2 +-
4 files changed, 2 insertions(+), 61 deletions(-)
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index ec64264..b721764 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -71,22 +71,6 @@ config MAKALU
help
This option enables support for the AMCC PPC405EX board.
-#config REDWOOD_5
-# bool "Redwood-5"
-# depends on 40x
-# default n
-# select STB03xxx
-# help
-# This option enables support for the IBM STB04 evaluation board.
-
-#config REDWOOD_6
-# bool "Redwood-6"
-# depends on 40x
-# default n
-# select STB03xxx
-# help
-# This option enables support for the IBM STBx25xx evaluation board.
-
#config SYCAMORE
# bool "Sycamore"
# depends on 40x
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index f22bc9f..b5ebb72 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -321,7 +321,7 @@ config MTD_CFI_FLAGADM
config MTD_REDWOOD
tristate "CFI Flash devices mapped on IBM Redwood"
- depends on MTD_CFI && ( REDWOOD_4 || REDWOOD_5 || REDWOOD_6 )
+ depends on MTD_CFI && REDWOOD_4
help
This enables access routines for the flash chips on the IBM
Redwood board. If you have one of these boards and would like to
diff --git a/drivers/mtd/maps/redwood.c b/drivers/mtd/maps/redwood.c
index 933c0b6..d2c9db0 100644
--- a/drivers/mtd/maps/redwood.c
+++ b/drivers/mtd/maps/redwood.c
@@ -22,8 +22,6 @@
#include <asm/io.h>
-#if !defined (CONFIG_REDWOOD_6)
-
#define WINDOW_ADDR 0xffc00000
#define WINDOW_SIZE 0x00400000
@@ -69,47 +67,6 @@ static struct mtd_partition redwood_flash_partitions[] = {
}
};
-#else /* CONFIG_REDWOOD_6 */
-/* FIXME: the window is bigger - armin */
-#define WINDOW_ADDR 0xff800000
-#define WINDOW_SIZE 0x00800000
-
-#define RW_PART0_OF 0
-#define RW_PART0_SZ 0x400000 /* 4 MiB data */
-#define RW_PART1_OF RW_PART0_OF + RW_PART0_SZ
-#define RW_PART1_SZ 0x10000 /* 64K VPD */
-#define RW_PART2_OF RW_PART1_OF + RW_PART1_SZ
-#define RW_PART2_SZ 0x400000 - (0x10000 + 0x20000)
-#define RW_PART3_OF RW_PART2_OF + RW_PART2_SZ
-#define RW_PART3_SZ 0x20000
-
-static struct mtd_partition redwood_flash_partitions[] = {
- {
- .name = "Redwood filesystem",
- .offset = RW_PART0_OF,
- .size = RW_PART0_SZ
- },
- {
- .name = "Redwood OpenBIOS Vital Product Data",
- .offset = RW_PART1_OF,
- .size = RW_PART1_SZ,
- .mask_flags = MTD_WRITEABLE /* force read-only */
- },
- {
- .name = "Redwood kernel",
- .offset = RW_PART2_OF,
- .size = RW_PART2_SZ
- },
- {
- .name = "Redwood OpenBIOS",
- .offset = RW_PART3_OF,
- .size = RW_PART3_SZ,
- .mask_flags = MTD_WRITEABLE /* force read-only */
- }
-};
-
-#endif /* CONFIG_REDWOOD_6 */
-
struct map_info redwood_flash_map = {
.name = "IBM Redwood",
.size = WINDOW_SIZE,
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ce2fcdd..313d306 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -913,7 +913,7 @@ config SMC91X
tristate "SMC 91C9x/91C1xxx support"
select CRC32
select MII
- depends on ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH || \
+ depends on ARM || M32R || SUPERH || \
MIPS || BLACKFIN || MN10300 || COLDFIRE
help
This is a driver for SMC's 91x series of Ethernet chipsets,
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox