* Re: [PATCH] tunnels: Optimize tx path
From: David Miller @ 2009-10-05 7:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4ABB233E.5050503@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 24 Sep 2009 09:43:58 +0200
> We currently dirty a cache line to update tunnel device stats
> (tx_packets/tx_bytes). We better use the txq->tx_bytes/tx_packets
> counters that already are present in cpu cache, in the cache
> line shared with txq->_xmit_lock
>
> This patch extends IPTUNNEL_XMIT() macro to use txq pointer
> provided by the caller.
>
> Also &tunnel->dev->stats can be replaced by &dev->stats
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] icmp: No need to call sk_write_space()
From: David Miller @ 2009-10-05 7:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4ABBEFD3.6060407@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 25 Sep 2009 00:16:51 +0200
> We can make icmp messages tx completion callback a litle bit faster.
>
> Setting SOCK_USE_WRITE_QUEUE sk flag tells sock_wfree() to
> not call sk_write_space() on a socket we know no thread is posssibly
> waiting for write space. (on per cpu kernel internal icmp sockets only)
>
> This avoids the sock_def_write_space() call and
> read_lock(&sk->sk_callback_lock)/read_unlock(&sk->sk_callback_lock) calls
> as well.
>
> We avoid three atomic ops.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 19/21] drivers/net/bonding/: : use pr_fmt
From: David Miller @ 2009-10-05 7:12 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, fubar, bonding-devel, netdev
In-Reply-To: <ec7e258261ac67ba496f96d04c270cf89fc24deb.1254701151.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 4 Oct 2009 17:53:46 -0700
> Add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> Remove DRV_NAME from pr_<level>s
> Consolidate long format strings
> Remove some extra tab indents
> Remove some unnecessary ()s from pr_<level>s arguments
> Align pr_<level> arguments
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 20/21] drivers/net/tlan: use pr_<level> and add pr_fmt(fmt)
From: David Miller @ 2009-10-05 7:12 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, chessman, netdev
In-Reply-To: <d4468c1b062875f4b88ba94f4631232ecff9c27b.1254701151.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 4 Oct 2009 17:53:47 -0700
> Added #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> Converted printk(KERN_<level> to pr_<level>(
> Removed "TLAN: " prefixes
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 21/21] drivers/net/tlan.h: Convert printk(KERN_DEBUG to pr_dbg(
From: David Miller @ 2009-10-05 7:12 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, chessman, netdev
In-Reply-To: <29c66ee0bae26a0c352b4605e3f1fcbe0612f3a5.1254701151.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 4 Oct 2009 17:53:48 -0700
> Removed "TLAN: " prefix from debug printks, it's added by pr_fmt
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 3/4] net: Convert ethtool {get_stats,self_test}_count() ops to get_sset_count()
From: David Miller @ 2009-10-05 7:12 UTC (permalink / raw)
To: eilong
Cc: bhutchings, chien.tin.tung, faisal.latif, subbus, sathyap, benh,
jwboyer, alexander.h.duyck, netdev
In-Reply-To: <1254668841.2642.3.camel@lb-tlvb-eilong>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Sun, 4 Oct 2009 17:07:21 +0200
> On Thu, 2009-10-01 at 14:32 -0700, Ben Hutchings wrote:
>> These string query operations were supposed to be replaced by the
>> generic get_sset_count() starting in 2007. Convert the remaining
>> implementations.
>>
>> Also remove calls to these operations to initialise drvinfo->n_stats.
>> The ethtool core code already does that.
>>
>> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
>> ---
>> drivers/infiniband/hw/nes/nes_nic.c | 12 ++++---
>> drivers/net/benet/be_ethtool.c | 11 +++++--
>> drivers/net/bnx2x_main.c | 60 ++++++++++++++++++-----------------
>> drivers/net/ibm_newemac/core.c | 10 +++--
>> drivers/net/igbvf/ethtool.c | 25 +++++++-------
>> drivers/net/niu.c | 7 +++-
>> 6 files changed, 70 insertions(+), 55 deletions(-)
>>
> Thanks Ben, bnx2x tested and works just fine with this patch.
> Acked-by: Eilon Greenstein <eilong@broadcom.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/4] qeth: Convert ethtool get_stats_count() ops to get_sset_count()
From: David Miller @ 2009-10-05 7:13 UTC (permalink / raw)
To: bhutchings; +Cc: ursula.braun, frank.blaschka, linux-s390, netdev
In-Reply-To: <1254432272.2735.20.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 01 Oct 2009 22:24:32 +0100
> This string query operation was supposed to be replaced by the
> generic get_sset_count() starting in 2007. Convert qeth's
> implementation.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 2/4] tehuti: Convert ethtool get_stats_count() ops to get_sset_count()
From: David Miller @ 2009-10-05 7:13 UTC (permalink / raw)
To: bhutchings; +Cc: andy, baum, netdev
In-Reply-To: <1254432479.2735.24.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 01 Oct 2009 22:27:59 +0100
> This string query operation was supposed to be replaced by the
> generic get_sset_count() starting in 2007. Convert tehuti's
> implementation.
>
> Also remove the dummy self-test name which was not used since tehuti
> does not advertise any self-tests.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 4/4] ethtool: Remove support for obsolete string query operations
From: David Miller @ 2009-10-05 7:13 UTC (permalink / raw)
To: bhutchings; +Cc: netdev
In-Reply-To: <1254432783.2735.29.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 01 Oct 2009 22:33:03 +0100
> The in-tree implementations have all been converted to
> get_sset_count().
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] TI DaVinci EMAC: Minor macro related updates
From: David Miller @ 2009-10-05 7:14 UTC (permalink / raw)
To: chaithrika; +Cc: netdev, davinci-linux-open-source
In-Reply-To: <1254428719-13960-1-git-send-email-chaithrika@ti.com>
From: Chaithrika U S <chaithrika@ti.com>
Date: Thu, 1 Oct 2009 16:25:19 -0400
> Use BIT for macro definitions wherever possible, remove
> unused and redundant macros.
>
> Signed-off-by: Chaithrika U S <chaithrika@ti.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 21/21] drivers/net/tlan.h: Convert printk(KERN_DEBUG to pr_dbg(
From: Joe Perches @ 2009-10-05 7:16 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, chessman, netdev
In-Reply-To: <20091005.001240.111554671.davem@davemloft.net>
On Mon, 2009-10-05 at 00:12 -0700, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Sun, 4 Oct 2009 17:53:48 -0700
> > Removed "TLAN: " prefix from debug printks, it's added by pr_fmt
> > Signed-off-by: Joe Perches <joe@perches.com>
> Applied to net-next-2.6
Patches 20 and 21 depend on patch 1, which introduces pr_dbg
to kernel.h. Compile failure otherwise.
^ permalink raw reply
* Re: [PATCH 21/21] drivers/net/tlan.h: Convert printk(KERN_DEBUG to pr_dbg(
From: David Miller @ 2009-10-05 7:20 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, chessman, netdev
In-Reply-To: <1254726974.1799.315.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Mon, 05 Oct 2009 00:16:14 -0700
> On Mon, 2009-10-05 at 00:12 -0700, David Miller wrote:
>> From: Joe Perches <joe@perches.com>
>> Date: Sun, 4 Oct 2009 17:53:48 -0700
>> > Removed "TLAN: " prefix from debug printks, it's added by pr_fmt
>> > Signed-off-by: Joe Perches <joe@perches.com>
>> Applied to net-next-2.6
>
> Patches 20 and 21 depend on patch 1, which introduces pr_dbg
> to kernel.h. Compile failure otherwise.
Ok, I'll toss them then.
Someone else merge this stuff:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] net: Support inclusion of <linux/socket.h> before <sys/socket.h>
From: David Miller @ 2009-10-05 7:24 UTC (permalink / raw)
To: ben; +Cc: netdev, waldi, manuel, 538372
In-Reply-To: <1254627764.2395.48.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 04 Oct 2009 04:42:44 +0100
> From: Bastian Blank <waldi@debian.org>
>
> The following user-space program fails to compile:
>
> #include <linux/socket.h>
> #include <sys/socket.h>
> int main() { return 0; }
>
> The reason is that <linux/socket.h> tests __GLIBC__ to decide whether it
> should define various structures and macros that are now defined for
> user-space by <sys/socket.h>, but __GLIBC__ is not defined if no libc
> headers have yet been included.
>
> It seems safe to drop support for libc 5 now.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fair enough, applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] TCPCT+1: initial SYN exchange with SYNACK data
From: David Miller @ 2009-10-05 7:27 UTC (permalink / raw)
To: william.allen.simpson; +Cc: netdev
In-Reply-To: <4AC79905.1030904@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Sat, 03 Oct 2009 14:33:41 -0400
> @@ -406,6 +454,32 @@ struct tcp_sock {
...
> + struct tcp_s_data_payload *s_data_payload;
...
> + struct tcp_cookie_pair *cookie_pair;
...
> + u16 s_data_desired; /* bytes */
...
> + u8 cookie_desired; /* bytes */
> + u8 s_data_in:1,
> + s_data_out:1,
> + cookie_in_always:1,
> + cookie_out_never:1;
struct tcp_sock is already WAY TOO BIG on 64-bit systems, adding 20
more bytes to it for some odd-ball feature is not something I'm
willing to do, sorry.
^ permalink raw reply
* Re: [PATCH] inet_peer: Optimize inet_getid()
From: Eric Dumazet @ 2009-10-05 7:38 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20091005.000818.95127796.davem@davemloft.net>
David Miller a écrit :
>
> I can't apply this, it's going to break the build on some
> architectures.
>
> For example, sparc64 only supports cmpxchg on u32 and u64
> objects, but you're trying to use it on a u16 here.
Oops, thanks for the info David !
^ permalink raw reply
* Re: [PATCH kernel 2.6.32-rc1] pcnet_cs: add cis of National Semicondoctor's multifunction pcmcia card
From: David Miller @ 2009-10-05 7:40 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20091004073257.52a6624b.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Sun, 4 Oct 2009 07:32:57 +0900
>
> pcnet_cs,serial_cs:
>
> add cis of National Semicondoctor's lan&modem mulitifunction pcmcia card,
> NE2K, tamarack ethernet card,
> and some serial card(COMpad2, COMpad4).
>
>
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: export device speed and duplex via sysfs
From: David Miller @ 2009-10-05 7:44 UTC (permalink / raw)
To: andy; +Cc: bhutchings, netdev
In-Reply-To: <20091002200141.GB1639@gospo.rdu.redhat.com>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Fri, 2 Oct 2009 16:01:41 -0400
> I took a look at /sys/class/net/ethX/ and felt like the information was
> pretty complete with the exception of the link speed and duplex, so I
> thought it would be a good place to add it. I personally wouldn't mind
> having most of the information presented in ethtool available via sysfs,
> but I figured I would walk before running.
I have no objections to this, I applied v2 of your patch to
net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH 0/4] More device type integration
From: David Miller @ 2009-10-05 7:44 UTC (permalink / raw)
To: marcel; +Cc: netdev, johannes, greg
In-Reply-To: <cover.1254495724.git.marcel@holtmann.org>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Fri, 2 Oct 2009 17:15:24 +0200
> I followed the work from Johannes and made sure we can register the
> device type for wireless devices via the netdev notifier callback for
> all cfg80211 based devices. This way we don't have to touch any of
> the drivers.
>
> For the mobile broadband cards from Ericsson, the device type is now
> set to "wwan" and it also uses "wwan%d" for the default interface name.
Looks good, all applied to net-next-2.6
Thanks!
^ permalink raw reply
* Re: [PATCH] TCPCT+1: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-10-05 7:45 UTC (permalink / raw)
To: netdev
In-Reply-To: <4AC79905.1030904@gmail.com>
As I'm new to Linux kernel development, this was based entirely on code
previously reviewed (by Miller), as that seemed a good path for me to learn
proper coding and style.
Now that I'm trying to grok Linux locking functions for the next patch, I've
noticed that setsockopt code uses lock_sock(), but getsockopt doesn't. In a
preemptive kernel, or with SMP, isn't there a possibility that these socket
values could be modified or destroyed at the same time?
I'm especially concerned here, as there are kref blocks, and they could be
left pointing into the weeds?
^ permalink raw reply
* Re: [PATCH] TCPCT+1: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-10-05 7:58 UTC (permalink / raw)
Cc: netdev
In-Reply-To: <20091005.002719.146534039.davem@davemloft.net>
David Miller wrote:
> From: William Allen Simpson <william.allen.simpson@gmail.com>
> Date: Sat, 03 Oct 2009 14:33:41 -0400
>
>> @@ -406,6 +454,32 @@ struct tcp_sock {
> ...
>> + struct tcp_s_data_payload *s_data_payload;
> ...
>> + struct tcp_cookie_pair *cookie_pair;
> ...
>> + u16 s_data_desired; /* bytes */
> ...
>> + u8 cookie_desired; /* bytes */
>> + u8 s_data_in:1,
>> + s_data_out:1,
>> + cookie_in_always:1,
>> + cookie_out_never:1;
>
> struct tcp_sock is already WAY TOO BIG on 64-bit systems, adding 20
> more bytes to it for some odd-ball feature is not something I'm
> willing to do, sorry.
>
I see we're cross-posting at the same time.... Since in your previous
review (last year) this issue was not mentioned, is there some other
data organization that you would suggest?
http://article.gmane.org/gmane.linux.network/102779
"This looks mostly fine to me. I would even advocate not using a config
option for this."
Perhaps you would prefer this as a config option after all?
As for "odd-ball feature", of course this is the initial pass on a much
larger project....
^ permalink raw reply
* Re: [PATCH] TCPCT+1: initial SYN exchange with SYNACK data
From: David Miller @ 2009-10-05 8:06 UTC (permalink / raw)
To: william.allen.simpson; +Cc: netdev
In-Reply-To: <4AC9A714.7060903@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Mon, 05 Oct 2009 03:58:12 -0400
> I see we're cross-posting at the same time.... Since in your previous
> review (last year) this issue was not mentioned, is there some other
> data organization that you would suggest?
>
> http://article.gmane.org/gmane.linux.network/102779
>
> "This looks mostly fine to me. I would even advocate not using a
> config
> option for this."
I'm looking at the patch more closely, and as I learn more
things about your change, my position changes.
> Perhaps you would prefer this as a config option after all?
No, then nobody is going to deploy this thing (meaning it really will
be useless), or everyone will and everyone will enable it and thus eat
the space.
It's bad either way.
Store the data either somewhere else or in an extremely compact form.
^ permalink raw reply
* Re: [PATCH] TCPCT+1: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-10-05 8:11 UTC (permalink / raw)
To: netdev
In-Reply-To: <4AC9A714.7060903@gmail.com>
William Allen Simpson wrote:
> David Miller wrote:
>> struct tcp_sock is already WAY TOO BIG on 64-bit systems, adding 20
>> more bytes to it for some odd-ball feature is not something I'm
>> willing to do, sorry.
>>
> I see we're cross-posting at the same time.... Since in your previous
> review (last year) this issue was not mentioned, is there some other
> data organization that you would suggest?
>
> http://article.gmane.org/gmane.linux.network/102779
>
> "This looks mostly fine to me. I would even advocate not using a config
> option for this."
>
As a quick followup, I wish this had been raised in my previous posting,
where I'd given the headers, for exactly this kind of feedback. :-)
Given that size is now a concern, would a single kref pointer with a u16
field for flags be acceptable? I could bury the rest in the kref block.
Would that be acceptable without a config option?
^ permalink raw reply
* Re: [PATCH 1/7] mlx4: Added interrupts test support
From: Yevgeny Petrilin @ 2009-10-05 11:16 UTC (permalink / raw)
To: Roland Dreier; +Cc: davem, netdev
In-Reply-To: <adaeipmqxmv.fsf@cisco.com>
Roland Dreier wrote:
> This feels like a pretty risky thing to do while the device might be
> handling all sorts of other traffic at the same time. Are you sure
> there are no races you expose here?
We did testing on this, during heavy traffic.
A race can happen when there are two processes that execute that test simultaneously,
but the tests always executed from Ethtool context.
I will add additional protection in case somebody tries to execute this test from another context.
> Have you actually seen cases where
> the interrupt test during initialization works but then this test
> catches a problem? (My experience has been that if any MSI-X interrupts
> work from a device, then they'll all work)
It also checks that all the EQs work properly. During initialization we only check the asynchronous EQ
^ permalink raw reply
* Re: [PATCH] TCPCT+1: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-10-05 8:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091005.010630.214808506.davem@davemloft.net>
David Miller wrote:
> I'm looking at the patch more closely, and as I learn more
> things about your change, my position changes.
>
>> Perhaps you would prefer this as a config option after all?
>
> No, then nobody is going to deploy this thing (meaning it really will
> be useless), or everyone will and everyone will enable it and thus eat
> the space.
>
> It's bad either way.
>
> Store the data either somewhere else or in an extremely compact form.
>
More cross-posting, a good thing for responsiveness....
OK, no config option.
This will be widely deployed. Deployment in DNS root servers is
expected by December. It will be hammered with 600,000+ queries per
minute. Does that impact your design expectations?
Tomorrow, I'll send out a new patch with everything buried in a single
kref, the various tests will only be a trifle slower....
^ permalink raw reply
* Re: [PATCH] TCPCT+1: initial SYN exchange with SYNACK data
From: David Miller @ 2009-10-05 8:45 UTC (permalink / raw)
To: william.allen.simpson; +Cc: netdev
In-Reply-To: <4AC9AA3E.2090001@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Mon, 05 Oct 2009 04:11:42 -0400
> Given that size is now a concern, would a single kref pointer with a
> u16 field for flags be acceptable? I could bury the rest in the
> kref block.
>
> Would that be acceptable without a config option?
Then we'll eat an atomic operation every connect() or something
like that?
That's bad too. We're trying desperately to remove as many
atomic operations as possible from the socket paths.
Compress your state, really compress it, don't just externalize
it somewhere else in exchange for a different cost.
^ permalink raw reply
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