* [PATCH 2/2] ethtool: add RSS command flag
From: Stephen Hemminger @ 2010-03-28 22:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100328154448.701c89ee@nehalam>
Add RSS offload option to ethtool command.
Also, fix ethtool header to be pure version from net-next.
ethtool-copy.h should be generated by kernel 'make install_headers' to ensure
that all fields match exactly.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
ethtool-copy.h | 32 +++++++++++++++++++++++++-------
ethtool.8 | 4 ++++
ethtool.c | 43 ++++++++++++++++++++++++++++++++++++++-----
3 files changed, 67 insertions(+), 12 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 8681f5e..a20fe84 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -36,7 +36,7 @@ struct ethtool_cmd {
__u32 reserved[2];
};
-static inline void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
+static __inline__ void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
__u32 speed)
{
@@ -44,7 +44,7 @@ static inline void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
ep->speed_hi = (__u16)(speed >> 16);
}
-static inline __u32 ethtool_cmd_speed(struct ethtool_cmd *ep)
+static __inline__ __u32 ethtool_cmd_speed(struct ethtool_cmd *ep)
{
return (ep->speed_hi << 16) | ep->speed;
}
@@ -61,6 +61,13 @@ struct ethtool_drvinfo {
/* For PCI devices, use pci_name(pci_dev). */
char reserved1[32];
char reserved2[12];
+ /*
+ * Some struct members below are filled in
+ * using ops->get_sset_count(). Obtaining
+ * this info from ethtool_drvinfo is now
+ * deprecated; Use ETHTOOL_GSSET_INFO
+ * instead.
+ */
__u32 n_priv_flags; /* number of flags valid in ETHTOOL_GPFLAGS */
__u32 n_stats; /* number of u64's from ETHTOOL_GSTATS */
__u32 testinfo_len;
@@ -253,6 +260,17 @@ struct ethtool_gstrings {
__u8 data[0];
};
+struct ethtool_sset_info {
+ __u32 cmd; /* ETHTOOL_GSSET_INFO */
+ __u32 reserved;
+ __u64 sset_mask; /* input: each bit selects an sset to query */
+ /* output: each bit a returned sset */
+ __u32 data[0]; /* ETH_SS_xxx count, in order, based on bits
+ in sset_mask. One bit implies one
+ __u32, two bits implies two
+ __u32's, etc. */
+};
+
enum ethtool_test_flags {
ETH_TEST_FL_OFFLINE = (1 << 0), /* online / offline */
ETH_TEST_FL_FAILED = (1 << 1), /* test passed / failed */
@@ -292,6 +310,7 @@ struct ethtool_perm_addr {
enum ethtool_flags {
ETH_FLAG_LRO = (1 << 15), /* LRO is enabled */
ETH_FLAG_NTUPLE = (1 << 27), /* N-tuple filters enabled */
+ ETH_FLAG_RSS = (1 << 28),
};
/* The following structures are for supporting RX network flow
@@ -389,8 +408,6 @@ struct ethtool_rx_ntuple_flow_spec {
#define ETHTOOL_RXNTUPLE_ACTION_DROP -1
};
-#define ETHTOOL_MAX_NTUPLE_LIST_ENTRY 1024
-#define ETHTOOL_MAX_NTUPLE_STRING_PER_ENTRY 14
struct ethtool_rx_ntuple {
__u32 cmd;
struct ethtool_rx_ntuple_flow_spec fs;
@@ -408,6 +425,7 @@ struct ethtool_flash {
char data[ETHTOOL_FLASH_MAX_FILENAME];
};
+
/* CMDs currently supported */
#define ETHTOOL_GSET 0x00000001 /* Get settings. */
#define ETHTOOL_SSET 0x00000002 /* Set settings. */
@@ -463,9 +481,9 @@ struct ethtool_flash {
#define ETHTOOL_SRXCLSRLINS 0x00000032 /* Insert RX classification rule */
#define ETHTOOL_FLASHDEV 0x00000033 /* Flash firmware to device */
#define ETHTOOL_RESET 0x00000034 /* Reset hardware */
-
-#define ETHTOOL_SRXNTUPLE 0x00000035 /* Add an n-tuple filter to device */
-#define ETHTOOL_GRXNTUPLE 0x00000036 /* Get n-tuple filters from device */
+#define ETHTOOL_SRXNTUPLE 0x00000035 /* Add an n-tuple filter to device */
+#define ETHTOOL_GRXNTUPLE 0x00000036 /* Get n-tuple filters from device */
+#define ETHTOOL_GSSET_INFO 0x00000037 /* Get string set info */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/ethtool.8 b/ethtool.8
index eb6430b..a5afe13 100644
--- a/ethtool.8
+++ b/ethtool.8
@@ -170,6 +170,7 @@ ethtool \- Display or change ethernet card settings
.B2 gso on off
.B2 gro on off
.B2 lro on off
+.B2 rss on off
.B ethtool \-p|\-\-identify
.I ethX
@@ -362,6 +363,9 @@ Specifies whether generic receive offload should be enabled
.A2 lro on off
Specifies whether large receive offload should be enabled
.TP
+.A2 rss on off
+Specifies whether Receive Side Scaling hashing should be enabled
+.TP
.B \-p \-\-identify
Initiates adapter-specific action intended to enable an operator to
easily identify the adapter by sight. Typically this involves
diff --git a/ethtool.c b/ethtool.c
index fc9e419..8b6cc77 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -173,6 +173,8 @@ static struct option {
" [ gro on|off ]\n"
" [ lro on|off ]\n"
" [ ntuple on|off ]\n"
+ " [ rss on|off ]\n"
+
},
{ "-i", "--driver", MODE_GDRV, "Show driver information" },
{ "-d", "--register-dump", MODE_GREGS, "Do a register dump",
@@ -257,6 +259,7 @@ static int off_gso_wanted = -1;
static int off_lro_wanted = -1;
static int off_gro_wanted = -1;
static int off_ntuple_wanted = -1;
+static int off_rss_wanted = -1;
static struct ethtool_pauseparam epause;
static int gpause_changed = 0;
@@ -382,6 +385,7 @@ static struct cmdline_info cmdline_offload[] = {
{ "lro", CMDL_BOOL, &off_lro_wanted, NULL },
{ "gro", CMDL_BOOL, &off_gro_wanted, NULL },
{ "ntuple", CMDL_BOOL, &off_ntuple_wanted, NULL },
+ { "rss", CMDL_BOOL, &off_rss_wanted, NULL },
};
static struct cmdline_info cmdline_pause[] = {
@@ -1526,7 +1530,7 @@ static int dump_coalesce(void)
}
static int dump_offload(int rx, int tx, int sg, int tso, int ufo, int gso,
- int gro, int lro, int ntuple)
+ int gro, int lro, int ntuple, int rss)
{
fprintf(stdout,
"rx-checksumming: %s\n"
@@ -1537,7 +1541,8 @@ static int dump_offload(int rx, int tx, int sg, int tso, int ufo, int gso,
"generic-segmentation-offload: %s\n"
"generic-receive-offload: %s\n"
"large-receive-offload: %s\n"
- "ntuple-filters: %s\n",
+ "ntuple-filters: %s\n"
+ "receive-side-scaling: %s\n",
rx ? "on" : "off",
tx ? "on" : "off",
sg ? "on" : "off",
@@ -1546,7 +1551,8 @@ static int dump_offload(int rx, int tx, int sg, int tso, int ufo, int gso,
gso ? "on" : "off",
gro ? "on" : "off",
lro ? "on" : "off",
- ntuple ? "on" : "off");
+ ntuple ? "on" : "off",
+ rss ? "on" : "off");
return 0;
}
@@ -1863,7 +1869,7 @@ static int do_goffload(int fd, struct ifreq *ifr)
{
struct ethtool_value eval;
int err, allfail = 1, rx = 0, tx = 0, sg = 0;
- int tso = 0, ufo = 0, gso = 0, gro = 0, lro = 0, ntuple = 0;
+ int tso = 0, ufo = 0, gso = 0, gro = 0, lro = 0, ntuple = 0, rss = 0;
fprintf(stdout, "Offload parameters for %s:\n", devname);
@@ -1935,6 +1941,7 @@ static int do_goffload(int fd, struct ifreq *ifr)
} else {
lro = (eval.data & ETH_FLAG_LRO) != 0;
ntuple = (eval.data & ETH_FLAG_NTUPLE) != 0;
+ rss = (eval.data & ETH_FLAG_RSS) != 0;
allfail = 0;
}
@@ -1953,7 +1960,7 @@ static int do_goffload(int fd, struct ifreq *ifr)
return 83;
}
- return dump_offload(rx, tx, sg, tso, ufo, gso, gro, lro, ntuple);
+ return dump_offload(rx, tx, sg, tso, ufo, gso, gro, lro, ntuple, rss);
}
static int do_soffload(int fd, struct ifreq *ifr)
@@ -2087,6 +2094,29 @@ static int do_soffload(int fd, struct ifreq *ifr)
return 93;
}
}
+ if (off_rss_wanted >= 0) {
+ changed = 1;
+ eval.cmd = ETHTOOL_GFLAGS;
+ eval.data = 0;
+ ifr->ifr_data = (caddr_t)&eval;
+ err = ioctl(fd, SIOCETHTOOL, ifr);
+ if (err) {
+ perror("Cannot get device flag settings");
+ return 91;
+ }
+
+ eval.cmd = ETHTOOL_SFLAGS;
+ if (off_rss_wanted)
+ eval.data |= ETH_FLAG_RSS;
+ else
+ eval.data &= ~ETH_FLAG_RSS;
+
+ err = ioctl(fd, SIOCETHTOOL, ifr);
+ if (err) {
+ perror("Cannot set n-tuple filter settings");
+ return 93;
+ }
+ }
if (!changed) {
fprintf(stdout, "no offload settings changed\n");
@@ -2655,6 +2685,9 @@ static int do_srxntuple(int fd, struct ifreq *ifr)
return 0;
}
+#define ETHTOOL_MAX_NTUPLE_LIST_ENTRY 1024
+#define ETHTOOL_MAX_NTUPLE_STRING_PER_ENTRY 14
+
static int do_grxntuple(int fd, struct ifreq *ifr)
{
struct ethtool_gstrings *strings;
--
1.6.3.3
^ permalink raw reply related
* Re: [RFC] GTSM for IPv6
From: Stephen Hemminger @ 2010-03-28 15:57 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: David Miller, netdev
In-Reply-To: <4BA71BDC.1080609@linux-ipv6.org>
On Mon, 22 Mar 2010 16:27:24 +0900
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> wrote:
> (2010/03/20 1:56), Stephen Hemminger wrote:
> > Also RFC doesn't explicitly address GTSM on IPV6.
> > Maybe the RFC editors think the problem will magically no longer exist
> > in IPv6 world because everyone will be using IPsec.
>
> > ---
> > include/linux/in6.h | 3 +++
> > include/linux/ipv6.h | 3 ++-
> > net/ipv6/ipv6_sockglue.c | 12 ++++++++++++
> > net/ipv6/tcp_ipv6.c | 17 ++++++++++++++---
> > 4 files changed, 31 insertions(+), 4 deletions(-)
>
> Why don't we have code for other protocols such as
> UDP etc? We already have similar protection in NDP,
> It seem to make sense.
>
> And, as many other socket options (such as IPV6_UNICAST_HOPS
> etc.) do, please accept value of -1 to set the system's
> default (0 so far).
>
> x < -1: return an error of EINVAL
> x == -1: use kernel default
> 0 <= x <= 255: use x
> x >= 256: return an error of EINVAL
>
> We may also want to have sysctl for it.
The choice was made with IPv4 to follow the precedent of FreeBSD.
And it makes sense to me to have IPv6 follow what IPv4 did.
It doesn't make sense as a sysctl value since the value is associated
with a socket. It requires both sides to cooperate and the path
has to be known. The sender sets the hop count to 255 and the receiver
knows the sender is at most N hops away. The receiver then sets the
MIN_HOPCOUNT value to 255 - N.
Implementing GTSM for UDP, SCTP, DCCP is left as an exercise for
the reader. It can't be done in the IP layer since the IP layer
does not a socket and shouldn't be looking it up.
^ permalink raw reply
* linux-next: build warning after merge of the tree
From: Stephen Rothwell @ 2010-03-28 23:31 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Kyle McMartin
[-- Attachment #1: Type: text/plain, Size: 676 bytes --]
Hi Dave,
After merging the tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/net/tulip/uli526x.c: In function 'uli526x_rx_packet':
drivers/net/tulip/uli526x.c:861: warning: assignment makes pointer from integer without a cast
Introduced by commit ac90a149361a331f697d5aa500bedcff22054669 ("tulip:
Fix null dereference in uli526x_rx_packet()") from the net-current tree.
There is a missing set of parentheses around an assignment in an "if"
condition ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
P.S. this commit is missing a SOB from its purported author
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: linux-next: build warning after merge of the tree
From: Stephen Rothwell @ 2010-03-29 0:15 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Kyle McMartin
In-Reply-To: <20100329103139.1a735227.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
On Mon, 29 Mar 2010 10:31:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Dave,
Of course I meant the net-current tree ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [ANNOUNCEMENT] NET: usb: sierra_net.c driver
From: Ben Hutchings @ 2010-03-29 0:44 UTC (permalink / raw)
To: sclark46
Cc: Marcel Holtmann, Elina Pasheva, David Brownell, Rory Filer,
netdev, linux-usb
In-Reply-To: <4BAFAA2C.8060604@earthlink.net>
On Sun, 2010-03-28 at 15:12 -0400, Stephen Clark wrote:
> On 03/28/2010 11:57 AM, Marcel Holtmann wrote:
> > Hi Elina,
> >
> >> +static const struct driver_info sierra_net_info_68A3 = {
> >> + .description = "Sierra Wireless USB-Ethernet Modem",
> >> + .flags = FLAG_ETHER | FLAG_SEND_ZLP,
> >> + .bind = sierra_net_bind,
> >> + .unbind = sierra_net_unbind,
> >> + .status = sierra_net_status,
> >> + .rx_fixup = sierra_net_rx_fixup,
> >> + .tx_fixup = sierra_net_tx_fixup,
> >> + .data = (unsigned long)&sierra_net_info_data_68A3,
> >> +};
> >
> > the FLAG_ETHER is wrong here. Please use FLAG_WWAN to clearly mark these
> > interfaces.
> >
> > Otherwise we have wrong DEVTYPE uevent assignments and userspace will
> > treat them as real Ethernet cards. And that should not happen. As a nice
> Why shouldn't that happen if they look like NIC cards?
[...]
This information is important for management interfaces. The user
doesn't care what your device looks like at the kernel level - they know
it's a wireless broadband device and they expect to see a device
labelled as such in Network Manager or whatever they use.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Lists, lists and more lists we have lots of good ones at fair prices
From: fetish @ 2010-03-29 0:47 UTC (permalink / raw)
To: news, news, nelson5903, newdoc
I have alot of good quality American Databases at decent prices. Contact me here: Jerome.Moore@discountdatamarket.tk for a complete catalog of what we have.
to terminate please send a blank message to rembox@discountdatamarket.tk
^ permalink raw reply
* Re: CVE-2009-4537
From: Neil Horman @ 2010-03-29 0:50 UTC (permalink / raw)
To: David Miller; +Cc: michael.s.gilbert, linux-kernel, netdev
In-Reply-To: <20100327.103600.246539458.davem@davemloft.net>
On Sat, Mar 27, 2010 at 10:36:00AM -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Sat, 27 Mar 2010 10:34:07 -0700 (PDT)
>
> > From: Michael Gilbert <michael.s.gilbert@gmail.com>
> > Date: Sat, 27 Mar 2010 14:21:00 -0400
> >
> >> Hi,
> >>
> >> CVE-2009-4537 has been disclosed without any upstream activity for a
> >> while now. Discussion about the issue dried up in January [0], and a
> >> patch had been proposed [1], but no arguments were seen either for or
> >> against it. Note that redhat has already shipped that in their various
> >> kernel security updates. Would it make sense to merge those changes
> >> officially?
> >
> > A different version of the fix went into the tree.
>
> Ignore me, that was a fix for a different problem.
>
> I was waiting for Francois to come up with a cleaner fix
> but he stopped working on it, so yes I should put in
> the fix you mention or something similar.
>
> Neil, can you formally submit a version of the r8169
> CVE for upstream?
>
> Thanks.
>
Absolutley, I'll review the CVE text and my origional patch tomorrow morning,
and submit the official patch tomorrow afternoon.
Thanks!
Neil
^ permalink raw reply
* Re: [PATCH] r8169: fix broken register writes
From: Al Viro @ 2010-03-29 1:03 UTC (permalink / raw)
To: Fran?ois Romieu; +Cc: Ben Hutchings, David Miller, timo.teras, ivecera, netdev
In-Reply-To: <20100328221924.GG30031@ZenIV.linux.org.uk>
On Sun, Mar 28, 2010 at 11:19:24PM +0100, Al Viro wrote:
> > > Thanks Fran?ois. Which hardware have you tested this on so far ?
> >
> > 10ec:8169 (rev 10) / RTL8169sb/8110sb / XID 10000000
> >
> > Timo's is a 10ec:8167 / RTL8169sc/8110sc / XID 18000000. He only tested
> > the MAC[04] part.
>
> FWIW, XID18000000 here (J7F4) loses MAC4 on shutdown; hadn't tested the patch
> yet. 2.6.26 (on that box) and 2.6.31 (on identical mb) work, 2.6.33 doesn't.
> I suspect that bisect would lead to commit cc098dc70 (i.e. the place where we
> started to set address on shutdown). One more data point: ifconfig hw ether
> done under 2.6.26 did restore the address. And that's the same function,
> isn't it?
As the matter of fact, ifconfig eth0 hw ether .... ends up zeroing upper
32 bits on old kernels once in a while.
What orders accesses as seen by PCI bus in
RTL_W8(Cfg9346, Cfg9346_Unlock);
RTL_W32(MAC0, low);
RTL_W32(MAC4, high);
RTL_W8(Cfg9346, Cfg9346_Lock);
anyway, and don't we need mmiowb() or two in there?
^ permalink raw reply
* Re: CVE-2009-4537
From: Ben Hoyt @ 2010-03-29 1:27 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100329005046.GA2157@localhost.localdomain>
Hi netdev,
We're working on some TCP networking stuff where the key is low
latency -- in other words, we don't really care about data throughput,
but rather getting the end-to-end TCP packet transfer time down.
I know there's quite a few networking folks and kernel hackers on this
list, so I thought I'd see if anyone was interested (or knows someone
who might be interested) in doing a few hours of consultancy work to
give us some pointers on this. I'm a competent programmer, but
kernel-level network programming is not my area of expertise.
I'm happy to receive some pointers via this list -- and others might
benefit from that too -- but I'm also keen on some dedicated
consultancy hours if anyone's interested.
Thanks,
Ben.
^ permalink raw reply
* Minimizing TCP latency
From: Ben Hoyt @ 2010-03-29 1:29 UTC (permalink / raw)
To: netdev
Oops, very sorry, I replied to an existing message but forgot to edit
the subject line to start a new thread. Try again:
Hi netdev,
We're working on some TCP networking stuff where the key is low
latency -- in other words, we don't really care about data throughput,
but rather getting the end-to-end TCP packet transfer time down.
I know there's quite a few networking folks and kernel hackers on this
list, so I thought I'd see if anyone was interested (or knows someone
who might be interested) in doing a few hours of consultancy work to
give us some pointers on this. I'm a competent programmer, but
kernel-level network programming is not my area of expertise.
I'm happy to receive some pointers via this list -- and others might
benefit from that too -- but I'm also keen on some dedicated
consultancy hours if anyone's interested.
Thanks,
Ben.
^ permalink raw reply
* Re: CVE-2009-4537
From: David Miller @ 2010-03-29 1:54 UTC (permalink / raw)
To: benhoyt; +Cc: netdev
In-Reply-To: <7c93bf1e1003281827x7565b0bds1c18d23d1607540e@mail.gmail.com>
First, please don't hijack an unrelated thread to start talking about
something different.
Second, the mailing lists at vger.kernel.org are not for making
employment of consultancy offers.
Thanks.
^ permalink raw reply
* Re: linux-next: build warning after merge of the tree
From: David Miller @ 2010-03-29 1:57 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, kyle
In-Reply-To: <20100329103139.1a735227.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 29 Mar 2010 10:31:39 +1100
> Hi Dave,
>
> After merging the tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> drivers/net/tulip/uli526x.c: In function 'uli526x_rx_packet':
> drivers/net/tulip/uli526x.c:861: warning: assignment makes pointer from integer without a cast
>
> Introduced by commit ac90a149361a331f697d5aa500bedcff22054669 ("tulip:
> Fix null dereference in uli526x_rx_packet()") from the net-current tree.
> There is a missing set of parentheses around an assignment in an "if"
> condition ...
Strange, it didn't warn here.
I just committed the following, let me know if it fixes
this.
Thanks!
tulip: Add missing parens.
As reported by Stephen Rothwell.
drivers/net/tulip/uli526x.c: In function 'uli526x_rx_packet':
drivers/net/tulip/uli526x.c:861: warning: assignment makes pointer from integer without a cast
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/tulip/uli526x.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c
index 90be57b..a4f09d4 100644
--- a/drivers/net/tulip/uli526x.c
+++ b/drivers/net/tulip/uli526x.c
@@ -858,7 +858,7 @@ static void uli526x_rx_packet(struct net_device *dev, struct uli526x_board_info
/* Good packet, send to upper layer */
/* Shorst packet used new SKB */
if ((rxlen < RX_COPY_SIZE) &&
- ((new_skb = dev_alloc_skb(rxlen + 2) != NULL))) {
+ (((new_skb = dev_alloc_skb(rxlen + 2)) != NULL))) {
skb = new_skb;
/* size less than COPY_SIZE, allocate a rxlen SKB */
skb_reserve(skb, 2); /* 16byte align */
--
1.7.0.3
^ permalink raw reply related
* Re: [patch] iwlwifi: range checking issue
From: Zhu Yi @ 2010-03-29 2:01 UTC (permalink / raw)
To: Dan Carpenter
Cc: Chatre, Reinette, Intel Linux Wireless, John W. Linville,
Kolekar, Abhijeet, Berg, Johannes, Guy, Wey-Yi W,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <20100328115500.GX5069@bicker>
On Sun, 2010-03-28 at 19:55 +0800, Dan Carpenter wrote:
> IWL_RATE_COUNT is 13 and IWL_RATE_COUNT_LEGACY is 12.
>
> IWL_RATE_COUNT_LEGACY is the right one here because iwl3945_rates
> doesn't support 60M and also that's how "rates" is defined in
> iwlcore_init_geos() from drivers/net/wireless/iwlwifi/iwl-core.c.
>
> rates = kzalloc((sizeof(struct ieee80211_rate) * IWL_RATE_COUNT_LEGACY),
> GFP_KERNEL);
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Zhu Yi <yi.zhu@intel.com>
Thanks,
-yi
^ permalink raw reply
* Re: linux-next: build warning after merge of the tree
From: Joe Perches @ 2010-03-29 2:15 UTC (permalink / raw)
To: David Miller; +Cc: sfr, netdev, linux-next, linux-kernel, kyle
In-Reply-To: <20100328.185707.161194820.davem@davemloft.net>
On Sun, 2010-03-28 at 18:57 -0700, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> > After merging the tree, today's linux-next build (x86_64 allmodconfig)
> > produced this warning:
> > drivers/net/tulip/uli526x.c: In function 'uli526x_rx_packet':
> > drivers/net/tulip/uli526x.c:861: warning: assignment makes pointer from integer without a cast
> I just committed the following, let me know if it fixes
> this.
> - ((new_skb = dev_alloc_skb(rxlen + 2) != NULL))) {
> + (((new_skb = dev_alloc_skb(rxlen + 2)) != NULL))) {
You've an extra () there.
A close paren could have been moved from after
the NULL to after the "+ 2"
I think it's more readable as:
(new_skb = dev_alloc_skb(rxlen + 2))) {
cheers, Joe
^ permalink raw reply
* Re: [PATCH] r8169: fix broken register writes
From: Al Viro @ 2010-03-29 2:17 UTC (permalink / raw)
To: Fran?ois Romieu; +Cc: Ben Hutchings, David Miller, timo.teras, ivecera, netdev
In-Reply-To: <20100329010346.GH30031@ZenIV.linux.org.uk>
On Mon, Mar 29, 2010 at 02:03:46AM +0100, Al Viro wrote:
> On Sun, Mar 28, 2010 at 11:19:24PM +0100, Al Viro wrote:
>
> > > > Thanks Fran?ois. Which hardware have you tested this on so far ?
> > >
> > > 10ec:8169 (rev 10) / RTL8169sb/8110sb / XID 10000000
> > >
> > > Timo's is a 10ec:8167 / RTL8169sc/8110sc / XID 18000000. He only tested
> > > the MAC[04] part.
> >
> > FWIW, XID18000000 here (J7F4) loses MAC4 on shutdown; hadn't tested the patch
> > yet. 2.6.26 (on that box) and 2.6.31 (on identical mb) work, 2.6.33 doesn't.
> > I suspect that bisect would lead to commit cc098dc70 (i.e. the place where we
> > started to set address on shutdown). One more data point: ifconfig hw ether
> > done under 2.6.26 did restore the address. And that's the same function,
> > isn't it?
>
> As the matter of fact, ifconfig eth0 hw ether .... ends up zeroing upper
> 32 bits on old kernels once in a while.
BTW, patch from upthread doesn't help on that box, and neither does
simple reordering of MAC0 and MAC4 writes. Adding reads of MAC0 and
MAC4 after corresponding writes seems to work.
^ permalink raw reply
* Re: [PATCH net-2.6] ipv6: Don't drop cache route entry unless timer actually expired.
From: David Miller @ 2010-03-29 2:34 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, guenter.roeck
In-Reply-To: <201003281715.o2SHFjai004362@94.43.138.210.xn.2iij.net>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Mon, 29 Mar 2010 02:15:45 +0900
> This is ipv6 variant of the commit 5e016cbf6.. ("ipv4: Don't drop
> redirected route cache entry unless PTMU actually expired")
> by Guenter Roeck <guenter.roeck@ericsson.com>.
>
> Remove cache route entry in ipv6_negative_advice() only if
> the timer is expired.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied, thanks a lot!
^ permalink raw reply
* Re: Minimizing TCP latency
From: Ben Hoyt @ 2010-03-29 2:43 UTC (permalink / raw)
To: netdev
In-Reply-To: <7c93bf1e1003281829h3ddba989w198df86ac9f2d27c@mail.gmail.com>
[In reply to David Miller:]
> First, please don't hijack an unrelated thread to start talking about
> something different.
I'm sorry, my mistake -- I apologized in the new thread.
> Second, the mailing lists at vger.kernel.org are not for making
> employment of consultancy offers.
Fair enough. Though another netdev reader advised me that this would
be a good place to ask.
I know brevity is the soul of wit, but it's not the most encouraging
for a list newbie to be told, "You're doing it wrong, and you're in
the wrong place." You never know, I may have something to contribute
after all is said and done. :-)
So, if this isn't the place to ask, do you have any pointers in the
right direction?
-Ben
^ permalink raw reply
* Re: Minimizing TCP latency
From: Ben Hoyt @ 2010-03-29 3:24 UTC (permalink / raw)
To: netdev
In-Reply-To: <7c93bf1e1003281829h3ddba989w198df86ac9f2d27c@mail.gmail.com>
> I'm happy to receive some pointers via this list [...]
Sorry, I should also have posted more about what I've done in terms of
reducing latency so far:
* We've already got TCP_NODELAY activated.
* We've also turned off interrupt coalescing on the network card (for
example, see http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html).
* We've modified our process's CPU affinity so it runs on a core by
itself, reducing interrupt-handling latency slightly further.
* Our code is written in C, and we've tried to keep it as close to the
kernel's socket calls as possible.
So we're currently looking further into ways to reduce latency, which
currently looks like it'll mean digging deeper into the kernel's
networking options and innards.
FYI, we're using RHE release 4 and kernel version 2.6.9 on x86_64 machines.
-Ben
^ permalink raw reply
* [PATCH net-next-2.6] net: __netif_receive_skb should be static
From: Eric Dumazet @ 2010-03-29 5:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/core/dev.c b/net/core/dev.c
index bcb3ed2..887aa84 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2621,7 +2621,7 @@ void netif_nit_deliver(struct sk_buff *skb)
rcu_read_unlock();
}
-int __netif_receive_skb(struct sk_buff *skb)
+static int __netif_receive_skb(struct sk_buff *skb)
{
struct packet_type *ptype, *pt_prev;
struct net_device *orig_dev;
^ permalink raw reply related
* Re: Minimizing TCP latency
From: Eric Dumazet @ 2010-03-29 5:34 UTC (permalink / raw)
To: Ben Hoyt; +Cc: netdev
In-Reply-To: <7c93bf1e1003282024p75e70011j31577b42f29cc153@mail.gmail.com>
Le lundi 29 mars 2010 à 16:24 +1300, Ben Hoyt a écrit :
> > I'm happy to receive some pointers via this list [...]
>
> Sorry, I should also have posted more about what I've done in terms of
> reducing latency so far:
>
> * We've already got TCP_NODELAY activated.
One machine sends messages, and messages are not aknowledged by other
part ? Is it one way communication ?
>
> * We've also turned off interrupt coalescing on the network card (for
> example, see http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html).
>
> * We've modified our process's CPU affinity so it runs on a core by
> itself, reducing interrupt-handling latency slightly further.
>
> * Our code is written in C, and we've tried to keep it as close to the
> kernel's socket calls as possible.
>
So we're currently looking further into ways to reduce latency, which
> currently looks like it'll mean digging deeper into the kernel's
> networking options and innards.
>
> FYI, we're using RHE release 4 and kernel version 2.6.9 on x86_64 machines.
What are the targets ? (time constraints)
Mono threaded application handling one tcp flow ?
Are you handling a very light load on few flows, or many flows ?
Are machines all in the same LAN ?
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: __netif_receive_skb should be static
From: David Miller @ 2010-03-29 6:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1269840292.2256.22.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 29 Mar 2010 07:24:52 +0200
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* linux-next: build failure after merge of the final tree (net tree related)
From: Stephen Rothwell @ 2010-03-29 6:43 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Tom Herbert, Eric Dumazet
Hi Dave,
After merging the final tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
net/core/net-sysfs.c:476: warning: 'struct netdev_rx_queue' declared inside parameter list
net/core/net-sysfs.c:476: warning: its scope is only this definition or declaration, which is probably not what you want
net/core/net-sysfs.c:478: warning: 'struct netdev_rx_queue' declared inside parameter list
net/core/net-sysfs.c: In function 'rx_queue_attr_show':
net/core/net-sysfs.c:489: error: dereferencing pointer to incomplete type
net/core/net-sysfs.c:489: warning: type defaults to 'int' in declaration of '__mptr'
net/core/net-sysfs.c:489: warning: initialization from incompatible pointer type
net/core/net-sysfs.c:489: error: invalid use of undefined type 'struct netdev_rx_queue'
net/core/net-sysfs.c:494: warning: passing argument 1 of 'attribute->show' from incompatible pointer type
net/core/net-sysfs.c:494: note: expected 'struct netdev_rx_queue *' but argument is of type 'struct netdev_rx_queue *'
(and many more)
Caused by commit 0a9627f2649a02bea165cfd529d7bcb625c2fcad ("rps: Receive
Packet Steering") from the net tree. struct netdev_rx_queue is protected by
CONFIG_RPS in netdevice.h, but uses are not so protected in net-sysfs.c.
I applied the following patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 29 Mar 2010 17:27:55 +1100
Subject: [PATCH] rps: fix net-sysfs build for !CONFIG_RPS
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
net/core/net-sysfs.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index c810042..95af841 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -467,6 +467,7 @@ static struct attribute_group wireless_group = {
};
#endif
+#ifdef CONFIG_RPS
/*
* RX queue sysfs structures and functions.
*/
@@ -677,6 +678,12 @@ static void rx_queue_remove_kobjects(struct net_device *net)
kset_unregister(net->queues_kset);
}
+#else /* CONFIG_RPS */
+
+static int rx_queue_register_kobjects(struct net_device *net) { return 0; }
+static void rx_queue_remove_kobjects(struct net_device *net) { }
+
+#endif /* CONFIG_RPS */
#endif /* CONFIG_SYSFS */
#ifdef CONFIG_HOTPLUG
--
1.7.0.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: Eric Dumazet @ 2010-03-29 6:52 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Tom Herbert
In-Reply-To: <20100329174300.512d83a8.sfr@canb.auug.org.au>
Le lundi 29 mars 2010 à 17:43 +1100, Stephen Rothwell a écrit :
> Hi Dave,
>
> After merging the final tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> net/core/net-sysfs.c:476: warning: 'struct netdev_rx_queue' declared inside parameter list
> net/core/net-sysfs.c:476: warning: its scope is only this definition or declaration, which is probably not what you want
> net/core/net-sysfs.c:478: warning: 'struct netdev_rx_queue' declared inside parameter list
> net/core/net-sysfs.c: In function 'rx_queue_attr_show':
> net/core/net-sysfs.c:489: error: dereferencing pointer to incomplete type
> net/core/net-sysfs.c:489: warning: type defaults to 'int' in declaration of '__mptr'
> net/core/net-sysfs.c:489: warning: initialization from incompatible pointer type
> net/core/net-sysfs.c:489: error: invalid use of undefined type 'struct netdev_rx_queue'
> net/core/net-sysfs.c:494: warning: passing argument 1 of 'attribute->show' from incompatible pointer type
> net/core/net-sysfs.c:494: note: expected 'struct netdev_rx_queue *' but argument is of type 'struct netdev_rx_queue *'
>
> (and many more)
>
> Caused by commit 0a9627f2649a02bea165cfd529d7bcb625c2fcad ("rps: Receive
> Packet Steering") from the net tree. struct netdev_rx_queue is protected by
> CONFIG_RPS in netdevice.h, but uses are not so protected in net-sysfs.c.
>
> I applied the following patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 29 Mar 2010 17:27:55 +1100
> Subject: [PATCH] rps: fix net-sysfs build for !CONFIG_RPS
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> net/core/net-sysfs.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
> index c810042..95af841 100644
> --- a/net/core/net-sysfs.c
> +++ b/net/core/net-sysfs.c
> @@ -467,6 +467,7 @@ static struct attribute_group wireless_group = {
> };
> #endif
>
> +#ifdef CONFIG_RPS
> /*
> * RX queue sysfs structures and functions.
> */
> @@ -677,6 +678,12 @@ static void rx_queue_remove_kobjects(struct net_device *net)
> kset_unregister(net->queues_kset);
> }
>
> +#else /* CONFIG_RPS */
> +
> +static int rx_queue_register_kobjects(struct net_device *net) { return 0; }
> +static void rx_queue_remove_kobjects(struct net_device *net) { }
> +
> +#endif /* CONFIG_RPS */
> #endif /* CONFIG_SYSFS */
>
> #ifdef CONFIG_HOTPLUG
> --
> 1.7.0.3
Thats right, this was on my first submission, but I forgot to add
net/core/net-sysfs.c in my second commit, sorry.
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: Eric Dumazet @ 2010-03-29 6:59 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Tom Herbert
In-Reply-To: <1269845561.2164.1.camel@edumazet-laptop>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Le lundi 29 mars 2010 à 08:52 +0200, Eric Dumazet a écrit :
> Le lundi 29 mars 2010 à 17:43 +1100, Stephen Rothwell a écrit :
> > Hi Dave,
> >
> > After merging the final tree, today's linux-next build (powerpc
> > ppc44x_defconfig) failed like this:
> >
> > net/core/net-sysfs.c:476: warning: 'struct netdev_rx_queue' declared inside parameter list
> > net/core/net-sysfs.c:476: warning: its scope is only this definition or declaration, which is probably not what you want
> > net/core/net-sysfs.c:478: warning: 'struct netdev_rx_queue' declared inside parameter list
> > net/core/net-sysfs.c: In function 'rx_queue_attr_show':
> > net/core/net-sysfs.c:489: error: dereferencing pointer to incomplete type
> > net/core/net-sysfs.c:489: warning: type defaults to 'int' in declaration of '__mptr'
> > net/core/net-sysfs.c:489: warning: initialization from incompatible pointer type
> > net/core/net-sysfs.c:489: error: invalid use of undefined type 'struct netdev_rx_queue'
> > net/core/net-sysfs.c:494: warning: passing argument 1 of 'attribute->show' from incompatible pointer type
> > net/core/net-sysfs.c:494: note: expected 'struct netdev_rx_queue *' but argument is of type 'struct netdev_rx_queue *'
> >
> > (and many more)
> >
> > Caused by commit 0a9627f2649a02bea165cfd529d7bcb625c2fcad ("rps: Receive
> > Packet Steering") from the net tree. struct netdev_rx_queue is protected by
> > CONFIG_RPS in netdevice.h, but uses are not so protected in net-sysfs.c.
> >
> > I applied the following patch for today:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 29 Mar 2010 17:27:55 +1100
> > Subject: [PATCH] rps: fix net-sysfs build for !CONFIG_RPS
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Oops, a cleaner patch would be :
[PATCH] rps: fix net-sysfs build for !CONFIG_RPS
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index f6b6bfe..2144a7f 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -466,6 +466,7 @@ static struct attribute_group wireless_group = {
};
#endif
+#ifdef CONFIG_RPS
/*
* RX queue sysfs structures and functions.
*/
@@ -675,7 +676,7 @@ static void rx_queue_remove_kobjects(struct net_device *net)
kobject_put(&net->_rx[i].kobj);
kset_unregister(net->queues_kset);
}
-
+#endif /* CONFIG_RPS */
#endif /* CONFIG_SYSFS */
#ifdef CONFIG_HOTPLUG
@@ -739,7 +740,7 @@ void netdev_unregister_kobject(struct net_device * net)
if (!net_eq(dev_net(net), &init_net))
return;
-#ifdef CONFIG_SYSFS
+#ifdef CONFIG_RPS
rx_queue_remove_kobjects(net);
#endif
@@ -782,7 +783,7 @@ int netdev_register_kobject(struct net_device *net)
if (error)
return error;
-#ifdef CONFIG_SYSFS
+#ifdef CONFIG_RPS
error = rx_queue_register_kobjects(net);
if (error) {
device_del(dev);
^ permalink raw reply related
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: Stephen Rothwell @ 2010-03-29 7:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, linux-next, linux-kernel, Tom Herbert
In-Reply-To: <1269845561.2164.1.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
Hi Eric,
On Mon, 29 Mar 2010 08:52:41 +0200 Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Thats right, this was on my first submission, but I forgot to add
> net/core/net-sysfs.c in my second commit, sorry.
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks for the confirmation.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ 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