Netdev List
 help / color / mirror / Atom feed
* 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] 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: 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: 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

* 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: 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

* 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: 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

* 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: [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

* 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

* 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: [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

* [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

* [PATCH 1/2] netdev: add support for Receive Side Scaling hash control
From: Stephen Hemminger @ 2010-03-28 22:44 UTC (permalink / raw)
  To: David Miller; +Cc: netdev

This adds ethtool and device feature flag to allow control
of Receive Side Scaling hashing supported by many modern
controllers.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
I am working on RSS for sky2 device, but the hardware isn't fully cooperating
but thought others might want to use same API.

--- a/include/linux/ethtool.h	2010-03-28 14:09:58.611267016 -0700
+++ b/include/linux/ethtool.h	2010-03-28 14:19:45.032516128 -0700
@@ -310,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),	/* RSS is enabled */
 };
 
 /* The following structures are for supporting RX network flow
--- a/include/linux/netdevice.h	2010-03-28 14:12:13.092517615 -0700
+++ b/include/linux/netdevice.h	2010-03-28 14:13:47.232915349 -0700
@@ -785,6 +785,7 @@ struct net_device {
 #define NETIF_F_SCTP_CSUM	(1 << 25) /* SCTP checksum offload */
 #define NETIF_F_FCOE_MTU	(1 << 26) /* Supports max FCoE MTU, 2158 bytes*/
 #define NETIF_F_NTUPLE		(1 << 27) /* N-tuple filters supported */
+#define NETIF_F_RSS		(1 << 28) /* Receive Side Scaling hash */
 
 	/* Segmentation offload features */
 #define NETIF_F_GSO_SHIFT	16
--- a/net/core/ethtool.c	2010-03-28 14:12:25.012207457 -0700
+++ b/net/core/ethtool.c	2010-03-28 14:19:41.548521569 -0700
@@ -121,7 +121,7 @@ int ethtool_op_set_ufo(struct net_device
  * NETIF_F_xxx values in include/linux/netdevice.h
  */
 static const u32 flags_dup_features =
-	(ETH_FLAG_LRO | ETH_FLAG_NTUPLE);
+	(ETH_FLAG_LRO | ETH_FLAG_NTUPLE | ETH_FLAG_RSS);
 
 u32 ethtool_op_get_flags(struct net_device *dev)
 {
@@ -152,6 +152,11 @@ int ethtool_op_set_flags(struct net_devi
 		features &= ~NETIF_F_NTUPLE;
 	}
 
+	if (data & ETH_FLAG_RSS)
+		features |= NETIF_F_RSS;
+	else
+		features &= ~NETIF_F_RSS;
+
 	dev->features = features;
 	return 0;
 }

^ permalink raw reply

* Re: [PATCH] r8169: fix broken register writes
From: Al Viro @ 2010-03-28 22:19 UTC (permalink / raw)
  To: Fran?ois Romieu; +Cc: Ben Hutchings, David Miller, timo.teras, ivecera, netdev
In-Reply-To: <20100328212858.GA4220@electric-eye.fr.zoreil.com>

On Sun, Mar 28, 2010 at 11:28:58PM +0200, Fran?ois Romieu wrote:
> Ben Hutchings <ben@decadent.org.uk> :
> [...]
> > 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?

Another interesting bit: unlike the older kernel, grep for eth0 in .33 dmesg

eth0: RTL8169sc/8110sc at 0xf87fc000, 00:30:18:a4:65:89, XID 18000000 IRQ 18
r8169: eth0: link down
ADDRCONF(NETDEV_UP): eth0: link is not ready
r8169: eth0: link up
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

where with .26 (with the same userland) had

eth0: RTL8169sc/8110sc at 0xf87fc000, 00:30:18:a4:65:89, XID 18000000 IRQ 18
r8169: eth0: link up
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Same for .31 on another box, modulo different address there...

^ permalink raw reply

* Re: [PATCH] r8169: fix broken register writes
From: François Romieu @ 2010-03-28 22:04 UTC (permalink / raw)
  To: David Miller; +Cc: ben, timo.teras, ivecera, netdev
In-Reply-To: <20100327.193815.242127373.davem@davemloft.net>

David Miller <davem@davemloft.net> :
[...]
> Probably the rest of the driver should be audited for other
> areas where we may end up having this problem.

Those look safe
- MAC0
- MAC4
- MAR0
- CounterAddrLow
- CounterAddrHigh
- TxDescStartAddrLow
- TxDescStartAddrHigh
- RxDescAddrLow
- RxDescAddrHigh

The other candidates are not used yet.

[...]
> 1) Coverage for all possible bug cases.
>
> 2) Real 64-bit accesses on 64-bit platforms.

I see your point but the MACx and MARx registers are nowhere documented
as 64 bit : MAC0 and MAC4 (0x00 to 0x07) span IDR[0..5] + two reserved
bytes while MARx are documented as MAR[7..0] (0x08 to 0x0f). It would
be nice if it happened to work though.

-- 
Ueimor

^ permalink raw reply

* Re: [PATCH] r8169: fix broken register writes
From: François Romieu @ 2010-03-28 21:28 UTC (permalink / raw)
  To: Ben Hutchings; +Cc: David Miller, timo.teras, ivecera, netdev
In-Reply-To: <1269737245.8653.162.camel@localhost>

Ben Hutchings <ben@decadent.org.uk> :
[...]
> 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.

Old stuff.

> I was hesitant to make changes because of the huge number of variants.

Things will be amended if they break and reverted if they get out of
control.

-- 
Ueimor

^ permalink raw reply

* Re: [ANNOUNCEMENT] NET: usb: sierra_net.c driver
From: Stephen Clark @ 2010-03-28 19:12 UTC (permalink / raw)
  To: Marcel Holtmann
  Cc: Elina Pasheva, David Brownell, Rory Filer,
	netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb
In-Reply-To: <1269791821.11714.202.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>

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?

> benefit the interface name will be wwan%d by default as well.
>
> Regards
>
> Marcel
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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

* [PATCH net-next trivial] MAINTAINERS: ipg: Jesse Huang's email address bounces
From: Joe Perches @ 2010-03-28 18:42 UTC (permalink / raw)
  To: Francois Romieu; +Cc: Sorbica Shieh, netdev, linux-kernel
In-Reply-To: <1269801345.1500.32.camel@Joe-Laptop.home>

Signed-off-by: Joe Perches <joe@perches.com>
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 28d4bf0..73a9e1a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2998,10 +2998,9 @@ F:	net/ipv4/netfilter/ipt_MASQUERADE.c
 IP1000A 10/100/1000 GIGABIT ETHERNET DRIVER
 M:	Francois Romieu <romieu@fr.zoreil.com>
 M:	Sorbica Shieh <sorbica@icplus.com.tw>
-M:	Jesse Huang <jesse@icplus.com.tw>
 L:	netdev@vger.kernel.org
 S:	Maintained
-F:	drivers/net/ipg.c
+F:	drivers/net/ipg.*
 
 IPATH DRIVER
 M:	Ralph Campbell <infinipath@qlogic.com>

^ permalink raw reply related

* [PATCH net-next trivial] drivers/net/ipg: Remove invalid IPG_DDEBUG_MSG uses, neaten
From: Joe Perches @ 2010-03-28 18:35 UTC (permalink / raw)
  To: Francois Romieu, Sorbica Shieh, Jesse Huang; +Cc: netdev, linux-kernel

Some no longer valid IPG_DDEBUG_MSG uses are removed
Validate IPG_DDEBUG_MSG arguments when not #defined
Neaten #defines
marco/macro typo correction

Signed-off-by: Joe Perches <joe@perches.com>
---
 drivers/net/ipg.c |    5 --
 drivers/net/ipg.h |  109 +++++++++++++++++++++++++++++-----------------------
 2 files changed, 61 insertions(+), 53 deletions(-)

diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index 150415e..0d7ad3f 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -1547,8 +1547,6 @@ static void ipg_reset_after_host_error(struct work_struct *work)
 		container_of(work, struct ipg_nic_private, task.work);
 	struct net_device *dev = sp->dev;
 
-	IPG_DDEBUG_MSG("DMACtrl = %8.8x\n", ioread32(sp->ioaddr + IPG_DMACTRL));
-
 	/*
 	 * Acknowledge HostError interrupt by resetting
 	 * IPG DMA and HOST.
@@ -1825,9 +1823,6 @@ static int ipg_nic_stop(struct net_device *dev)
 
 	netif_stop_queue(dev);
 
-	IPG_DDEBUG_MSG("RFDlistendCount = %i\n", sp->RFDlistendCount);
-	IPG_DDEBUG_MSG("RFDListCheckedCount = %i\n", sp->rxdCheckedCount);
-	IPG_DDEBUG_MSG("EmptyRFDListCount = %i\n", sp->EmptyRFDListCount);
 	IPG_DUMPTFDLIST(dev);
 
 	do {
diff --git a/drivers/net/ipg.h b/drivers/net/ipg.h
index dfc2541..6ce0273 100644
--- a/drivers/net/ipg.h
+++ b/drivers/net/ipg.h
@@ -29,7 +29,7 @@
 /* GMII based PHY IDs */
 #define		NS				0x2000
 #define		MARVELL				0x0141
-#define		ICPLUS_PHY		0x243
+#define		ICPLUS_PHY			0x243
 
 /* NIC Physical Layer Device MII register fields. */
 #define         MII_PHY_SELECTOR_IEEE8023       0x0001
@@ -96,31 +96,31 @@ enum ipg_regs {
 };
 
 /* Ethernet MIB statistic register offsets. */
-#define	IPG_OCTETRCVOK		0xA8
+#define	IPG_OCTETRCVOK			0xA8
 #define	IPG_MCSTOCTETRCVDOK		0xAC
 #define	IPG_BCSTOCTETRCVOK		0xB0
 #define	IPG_FRAMESRCVDOK		0xB4
 #define	IPG_MCSTFRAMESRCVDOK		0xB8
 #define	IPG_BCSTFRAMESRCVDOK		0xBE
 #define	IPG_MACCONTROLFRAMESRCVD	0xC6
-#define	IPG_FRAMETOOLONGERRRORS	0xC8
-#define	IPG_INRANGELENGTHERRORS	0xCA
-#define	IPG_FRAMECHECKSEQERRORS	0xCC
-#define	IPG_FRAMESLOSTRXERRORS	0xCE
-#define	IPG_OCTETXMTOK		0xD0
+#define	IPG_FRAMETOOLONGERRRORS		0xC8
+#define	IPG_INRANGELENGTHERRORS		0xCA
+#define	IPG_FRAMECHECKSEQERRORS		0xCC
+#define	IPG_FRAMESLOSTRXERRORS		0xCE
+#define	IPG_OCTETXMTOK			0xD0
 #define	IPG_MCSTOCTETXMTOK		0xD4
 #define	IPG_BCSTOCTETXMTOK		0xD8
 #define	IPG_FRAMESXMTDOK		0xDC
 #define	IPG_MCSTFRAMESXMTDOK		0xE0
-#define	IPG_FRAMESWDEFERREDXMT	0xE4
+#define	IPG_FRAMESWDEFERREDXMT		0xE4
 #define	IPG_LATECOLLISIONS		0xE8
 #define	IPG_MULTICOLFRAMES		0xEC
 #define	IPG_SINGLECOLFRAMES		0xF0
 #define	IPG_BCSTFRAMESXMTDOK		0xF6
-#define	IPG_CARRIERSENSEERRORS	0xF8
+#define	IPG_CARRIERSENSEERRORS		0xF8
 #define	IPG_MACCONTROLFRAMESXMTDOK	0xFA
-#define	IPG_FRAMESABORTXSCOLLS	0xFC
-#define	IPG_FRAMESWEXDEFERRAL	0xFE
+#define	IPG_FRAMESABORTXSCOLLS		0xFC
+#define	IPG_FRAMESWEXDEFERRAL		0xFE
 
 /* RMON statistic register offsets. */
 #define	IPG_ETHERSTATSCOLLISIONS			0x100
@@ -134,8 +134,8 @@ enum ipg_regs {
 #define	IPG_ETHERSTATSPKTS1024TO1518OCTESTSTRANSMIT	0x120
 #define	IPG_ETHERSTATSCRCALIGNERRORS			0x124
 #define	IPG_ETHERSTATSUNDERSIZEPKTS			0x128
-#define	IPG_ETHERSTATSFRAGMENTS			0x12C
-#define	IPG_ETHERSTATSJABBERS			0x130
+#define	IPG_ETHERSTATSFRAGMENTS				0x12C
+#define	IPG_ETHERSTATSJABBERS				0x130
 #define	IPG_ETHERSTATSOCTETS				0x134
 #define	IPG_ETHERSTATSPKTS				0x138
 #define	IPG_ETHERSTATSPKTS64OCTESTS			0x13C
@@ -154,10 +154,10 @@ enum ipg_regs {
 #define	IPG_ETHERSTATSDROPEVENTS			0xCE
 
 /* Serial EEPROM offsets */
-#define	IPG_EEPROM_CONFIGPARAM	0x00
+#define	IPG_EEPROM_CONFIGPARAM		0x00
 #define	IPG_EEPROM_ASICCTRL		0x01
 #define	IPG_EEPROM_SUBSYSTEMVENDORID	0x02
-#define	IPG_EEPROM_SUBSYSTEMID	0x03
+#define	IPG_EEPROM_SUBSYSTEMID		0x03
 #define	IPG_EEPROM_STATIONADDRESS0	0x10
 #define	IPG_EEPROM_STATIONADDRESS1	0x11
 #define	IPG_EEPROM_STATIONADDRESS2	0x12
@@ -168,16 +168,16 @@ enum ipg_regs {
 
 /* IOBaseAddress */
 #define         IPG_PIB_RSVD_MASK		0xFFFFFE01
-#define         IPG_PIB_IOBASEADDRESS	0xFFFFFF00
-#define         IPG_PIB_IOBASEADDRIND	0x00000001
+#define         IPG_PIB_IOBASEADDRESS		0xFFFFFF00
+#define         IPG_PIB_IOBASEADDRIND		0x00000001
 
 /* MemBaseAddress */
 #define         IPG_PMB_RSVD_MASK		0xFFFFFE07
-#define         IPG_PMB_MEMBASEADDRIND	0x00000001
+#define         IPG_PMB_MEMBASEADDRIND		0x00000001
 #define         IPG_PMB_MEMMAPTYPE		0x00000006
 #define         IPG_PMB_MEMMAPTYPE0		0x00000002
 #define         IPG_PMB_MEMMAPTYPE1		0x00000004
-#define         IPG_PMB_MEMBASEADDRESS	0xFFFFFE00
+#define         IPG_PMB_MEMBASEADDRESS		0xFFFFFE00
 
 /* ConfigStatus */
 #define IPG_CS_RSVD_MASK                0xFFB0
@@ -196,20 +196,20 @@ enum ipg_regs {
 
 /* TFDList, TFC */
 #define	IPG_TFC_RSVD_MASK			0x0000FFFF9FFFFFFF
-#define	IPG_TFC_FRAMEID			0x000000000000FFFF
+#define	IPG_TFC_FRAMEID				0x000000000000FFFF
 #define	IPG_TFC_WORDALIGN			0x0000000000030000
 #define	IPG_TFC_WORDALIGNTODWORD		0x0000000000000000
-#define	IPG_TFC_WORDALIGNTOWORD		0x0000000000020000
+#define	IPG_TFC_WORDALIGNTOWORD			0x0000000000020000
 #define	IPG_TFC_WORDALIGNDISABLED		0x0000000000030000
 #define	IPG_TFC_TCPCHECKSUMENABLE		0x0000000000040000
 #define	IPG_TFC_UDPCHECKSUMENABLE		0x0000000000080000
 #define	IPG_TFC_IPCHECKSUMENABLE		0x0000000000100000
 #define	IPG_TFC_FCSAPPENDDISABLE		0x0000000000200000
 #define	IPG_TFC_TXINDICATE			0x0000000000400000
-#define	IPG_TFC_TXDMAINDICATE		0x0000000000800000
+#define	IPG_TFC_TXDMAINDICATE			0x0000000000800000
 #define	IPG_TFC_FRAGCOUNT			0x000000000F000000
-#define	IPG_TFC_VLANTAGINSERT		0x0000000010000000
-#define	IPG_TFC_TFDDONE			0x0000000080000000
+#define	IPG_TFC_VLANTAGINSERT			0x0000000010000000
+#define	IPG_TFC_TFDDONE				0x0000000080000000
 #define	IPG_TFC_VID				0x00000FFF00000000
 #define	IPG_TFC_CFI				0x0000100000000000
 #define	IPG_TFC_USERPRIORITY			0x0000E00000000000
@@ -217,35 +217,35 @@ enum ipg_regs {
 /* TFDList, FragInfo */
 #define	IPG_TFI_RSVD_MASK			0xFFFF00FFFFFFFFFF
 #define	IPG_TFI_FRAGADDR			0x000000FFFFFFFFFF
-#define	IPG_TFI_FRAGLEN			0xFFFF000000000000LL
+#define	IPG_TFI_FRAGLEN				0xFFFF000000000000LL
 
 /* RFD data structure masks. */
 
 /* RFDList, RFS */
 #define	IPG_RFS_RSVD_MASK			0x0000FFFFFFFFFFFF
 #define	IPG_RFS_RXFRAMELEN			0x000000000000FFFF
-#define	IPG_RFS_RXFIFOOVERRUN		0x0000000000010000
+#define	IPG_RFS_RXFIFOOVERRUN			0x0000000000010000
 #define	IPG_RFS_RXRUNTFRAME			0x0000000000020000
 #define	IPG_RFS_RXALIGNMENTERROR		0x0000000000040000
 #define	IPG_RFS_RXFCSERROR			0x0000000000080000
 #define	IPG_RFS_RXOVERSIZEDFRAME		0x0000000000100000
-#define	IPG_RFS_RXLENGTHERROR		0x0000000000200000
+#define	IPG_RFS_RXLENGTHERROR			0x0000000000200000
 #define	IPG_RFS_VLANDETECTED			0x0000000000400000
 #define	IPG_RFS_TCPDETECTED			0x0000000000800000
 #define	IPG_RFS_TCPERROR			0x0000000001000000
 #define	IPG_RFS_UDPDETECTED			0x0000000002000000
 #define	IPG_RFS_UDPERROR			0x0000000004000000
 #define	IPG_RFS_IPDETECTED			0x0000000008000000
-#define	IPG_RFS_IPERROR			0x0000000010000000
+#define	IPG_RFS_IPERROR				0x0000000010000000
 #define	IPG_RFS_FRAMESTART			0x0000000020000000
 #define	IPG_RFS_FRAMEEND			0x0000000040000000
-#define	IPG_RFS_RFDDONE			0x0000000080000000
+#define	IPG_RFS_RFDDONE				0x0000000080000000
 #define	IPG_RFS_TCI				0x0000FFFF00000000
 
 /* RFDList, FragInfo */
 #define	IPG_RFI_RSVD_MASK			0xFFFF00FFFFFFFFFF
 #define	IPG_RFI_FRAGADDR			0x000000FFFFFFFFFF
-#define	IPG_RFI_FRAGLEN			0xFFFF000000000000LL
+#define	IPG_RFI_FRAGLEN				0xFFFF000000000000LL
 
 /* I/O Register masks. */
 
@@ -254,37 +254,37 @@ enum ipg_regs {
 
 /* Statistics Mask */
 #define	IPG_SM_ALL					0x0FFFFFFF
-#define	IPG_SM_OCTETRCVOK_FRAMESRCVDOK		0x00000001
-#define	IPG_SM_MCSTOCTETRCVDOK_MCSTFRAMESRCVDOK	0x00000002
-#define	IPG_SM_BCSTOCTETRCVDOK_BCSTFRAMESRCVDOK	0x00000004
+#define	IPG_SM_OCTETRCVOK_FRAMESRCVDOK			0x00000001
+#define	IPG_SM_MCSTOCTETRCVDOK_MCSTFRAMESRCVDOK		0x00000002
+#define	IPG_SM_BCSTOCTETRCVDOK_BCSTFRAMESRCVDOK		0x00000004
 #define	IPG_SM_RXJUMBOFRAMES				0x00000008
 #define	IPG_SM_TCPCHECKSUMERRORS			0x00000010
-#define	IPG_SM_IPCHECKSUMERRORS			0x00000020
+#define	IPG_SM_IPCHECKSUMERRORS				0x00000020
 #define	IPG_SM_UDPCHECKSUMERRORS			0x00000040
 #define	IPG_SM_MACCONTROLFRAMESRCVD			0x00000080
 #define	IPG_SM_FRAMESTOOLONGERRORS			0x00000100
 #define	IPG_SM_INRANGELENGTHERRORS			0x00000200
 #define	IPG_SM_FRAMECHECKSEQERRORS			0x00000400
 #define	IPG_SM_FRAMESLOSTRXERRORS			0x00000800
-#define	IPG_SM_OCTETXMTOK_FRAMESXMTOK		0x00001000
-#define	IPG_SM_MCSTOCTETXMTOK_MCSTFRAMESXMTDOK	0x00002000
-#define	IPG_SM_BCSTOCTETXMTOK_BCSTFRAMESXMTDOK	0x00004000
+#define	IPG_SM_OCTETXMTOK_FRAMESXMTOK			0x00001000
+#define	IPG_SM_MCSTOCTETXMTOK_MCSTFRAMESXMTDOK		0x00002000
+#define	IPG_SM_BCSTOCTETXMTOK_BCSTFRAMESXMTDOK		0x00004000
 #define	IPG_SM_FRAMESWDEFERREDXMT			0x00008000
-#define	IPG_SM_LATECOLLISIONS			0x00010000
-#define	IPG_SM_MULTICOLFRAMES			0x00020000
-#define	IPG_SM_SINGLECOLFRAMES			0x00040000
+#define	IPG_SM_LATECOLLISIONS				0x00010000
+#define	IPG_SM_MULTICOLFRAMES				0x00020000
+#define	IPG_SM_SINGLECOLFRAMES				0x00040000
 #define	IPG_SM_TXJUMBOFRAMES				0x00080000
 #define	IPG_SM_CARRIERSENSEERRORS			0x00100000
 #define	IPG_SM_MACCONTROLFRAMESXMTD			0x00200000
 #define	IPG_SM_FRAMESABORTXSCOLLS			0x00400000
-#define	IPG_SM_FRAMESWEXDEFERAL			0x00800000
+#define	IPG_SM_FRAMESWEXDEFERAL				0x00800000
 
 /* Countdown */
 #define	IPG_CD_RSVD_MASK		0x0700FFFF
 #define	IPG_CD_COUNT			0x0000FFFF
-#define	IPG_CD_COUNTDOWNSPEED	0x01000000
+#define	IPG_CD_COUNTDOWNSPEED		0x01000000
 #define	IPG_CD_COUNTDOWNMODE		0x02000000
-#define	IPG_CD_COUNTINTENABLED	0x04000000
+#define	IPG_CD_COUNTINTENABLED		0x04000000
 
 /* TxDMABurstThresh */
 #define IPG_TB_RSVD_MASK                0xFF
@@ -653,15 +653,28 @@ enum ipg_regs {
  * Miscellaneous macros.
  */
 
-/* Marco for printing debug statements. */
+/* Macros for printing debug statements. */
 #ifdef IPG_DEBUG
-#  define IPG_DEBUG_MSG(args...)
-#  define IPG_DDEBUG_MSG(args...) printk(KERN_DEBUG "IPG: " args)
+#  define IPG_DEBUG_MSG(fmt, args...)			\
+do {							\
+	if (0)						\
+		printk(KERN_DEBUG "IPG: " fmt, ##args);	\
+} while (0)
+#  define IPG_DDEBUG_MSG(fmt, args...)			\
+	printk(KERN_DEBUG "IPG: " fmt, ##args)
 #  define IPG_DUMPRFDLIST(args) ipg_dump_rfdlist(args)
 #  define IPG_DUMPTFDLIST(args) ipg_dump_tfdlist(args)
 #else
-#  define IPG_DEBUG_MSG(args...)
-#  define IPG_DDEBUG_MSG(args...)
+#  define IPG_DEBUG_MSG(fmt, args...)			\
+do {							\
+	if (0)						\
+		printk(KERN_DEBUG "IPG: " fmt, ##args);	\
+} while (0)
+#  define IPG_DDEBUG_MSG(fmt, args...)			\
+do {							\
+	if (0)						\
+		printk(KERN_DEBUG "IPG: " fmt, ##args);	\
+} while (0)
 #  define IPG_DUMPRFDLIST(args)
 #  define IPG_DUMPTFDLIST(args)
 #endif



^ permalink raw reply related

* [PATCH net-2.6] ipv6: Don't drop cache route entry unless timer actually expired.
From: YOSHIFUJI Hideaki @ 2010-03-28 17:15 UTC (permalink / raw)
  To: davem; +Cc: netdev, yoshfuji, guenter.roeck

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>
---
 net/ipv6/route.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 7fcb0e5..0d7713c 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -890,12 +890,17 @@ static struct dst_entry *ip6_negative_advice(struct dst_entry *dst)
 	struct rt6_info *rt = (struct rt6_info *) dst;
 
 	if (rt) {
-		if (rt->rt6i_flags & RTF_CACHE)
-			ip6_del_rt(rt);
-		else
+		if (rt->rt6i_flags & RTF_CACHE) {
+			if (rt6_check_expired(rt)) {
+				ip6_del_rt(rt);
+				dst = NULL;
+			}
+		} else {
 			dst_release(dst);
+			dst = NULL;
+		}
 	}
-	return NULL;
+	return dst;
 }
 
 static void ip6_link_failure(struct sk_buff *skb)
-- 
1.5.6.5


^ permalink raw reply related

* Re: [ANNOUNCEMENT] NET: usb: sierra_net.c driver
From: Marcel Holtmann @ 2010-03-28 15:57 UTC (permalink / raw)
  To: Elina Pasheva; +Cc: David Brownell, Rory Filer, netdev, linux-usb
In-Reply-To: <1269652919.30630.1.camel@Linuxdev3>

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
benefit the interface name will be wwan%d by default as well.

Regards

Marcel



^ permalink raw reply

* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: Herbert Xu @ 2010-03-28 14:32 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20100328135931.GA16430@gondor.apana.org.au>

On Sun, Mar 28, 2010 at 09:59:31PM +0800, Herbert Xu wrote:
> 
> I don't think they are quite the same.  The TCP time stamp is
> an attribute of the destination host, it doesn't vary depending
> on which route you take to reach the host.  The MTU on the other
> hand is an attribute of the route that reaches the host.

Here's a convoluted scheme that I just thought up as a compromise
between your wish to expel the metrics and maintaining the policy
routing semantics.

Instead of placing the metrics into the inetpeer, we create a new
global cache for them (let's call it the metrics cache for now).
However, we don't actually populate this cache every time we create
an rt object.  Instead, we only create an entry in this cache
when an event requires it, e.g., when we receive a PMTU message.

In order for this to then propagate to the rt objects, we increment
a genid in the inetpeer cache for the corresponding host.  This
genid is then checked by the rt object every time.  When it is
out of step, the rt object can perform a lookup in the metrics cache
to get the latest data.

Of course once an rt object has a pointer to an entry in the metrics
cache it doesn't need to check the genid anymore, until the metrics
data expires at which point this process can be repeated.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: Herbert Xu @ 2010-03-28 13:59 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20100328.064012.193708716.davem@davemloft.net>

On Sun, Mar 28, 2010 at 06:40:12AM -0700, David Miller wrote:
>
> Same for all the other metrics at the TCP level.

I don't think they are quite the same.  The TCP time stamp is
an attribute of the destination host, it doesn't vary depending
on which route you take to reach the host.  The MTU on the other
hand is an attribute of the route that reaches the host.

BTW, it appears that the inetpeer cache doesn't take namespaces
into account.  This means that information could potentially leak
from one namespace into another.  I'm not sure whether that's a
big deal or not but it's something for the namespaces folks to
consider.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox