* Re: mmotm 2010-03-23 - IPv6 warnings...
From: Stephen Hemminger @ 2010-03-28 3:32 UTC (permalink / raw)
To: David Miller; +Cc: Valdis.Kletnieks, akpm, netdev, linux-kernel
In-Reply-To: <20100325.232349.66185070.davem@davemloft.net>
On Thu, 25 Mar 2010 23:23:49 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Valdis.Kletnieks@vt.edu
> Date: Fri, 26 Mar 2010 02:18:22 -0400
>
> > Confirming looks like a good fix - no cruft in dmesg, and I have ipv6 addresses:
>
> Great, thanks for testing.
>
> Andrew your box should be good now too.
Thanks for fixing this.
--
^ permalink raw reply
* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: David Miller @ 2010-03-28 4:06 UTC (permalink / raw)
To: netdev; +Cc: herbert
In-Reply-To: <20100327.203120.98894145.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 27 Mar 2010 20:31:20 -0700 (PDT)
> The limited dst metric usage in DecNET could then be moved into
> the DecNET route entry struct. This way we don't have to support
> DecNET in the inetpeer cache just for the sake of it's metrics. :-)
And this is what that patch would look like:
decnet: Move route metrics into struct dn_route
This way we can move ipv4/ipv6 metrics into the inetpeer cache.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/dn_route.h | 23 +++++++++++++++++++++++
net/decnet/af_decnet.c | 4 ++--
net/decnet/dn_route.c | 35 ++++++++++++++++++-----------------
3 files changed, 43 insertions(+), 19 deletions(-)
diff --git a/include/net/dn_route.h b/include/net/dn_route.h
index 60c9f22..62b04db 100644
--- a/include/net/dn_route.h
+++ b/include/net/dn_route.h
@@ -80,8 +80,31 @@ struct dn_route {
unsigned rt_flags;
unsigned rt_type;
+
+ u32 metrics[RTAX_MAX];
};
+static inline u32 dn_dst_metric(const struct dst_entry *dst, int metric)
+{
+ struct dn_route *rt = (struct dn_route *) dst;
+ return rt->metrics[metric - 1];
+}
+
+static inline int dn_dst_metric_locked(const struct dst_entry *dst, int metric)
+{
+ return dn_dst_metric(dst, RTAX_LOCK) & (1 << metric);
+}
+
+static inline u32 dn_dst_mtu(const struct dst_entry *dst)
+{
+ u32 mtu = dn_dst_metric(dst, RTAX_MTU);
+ /*
+ * Alexey put it here, so ask him about it :)
+ */
+ barrier();
+ return mtu;
+}
+
extern void dn_route_init(void);
extern void dn_route_cleanup(void);
diff --git a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
index 2b494fa..83228a2 100644
--- a/net/decnet/af_decnet.c
+++ b/net/decnet/af_decnet.c
@@ -829,7 +829,7 @@ static int dn_confirm_accept(struct sock *sk, long *timeo, gfp_t allocation)
return -EINVAL;
scp->state = DN_CC;
- scp->segsize_loc = dst_metric(__sk_dst_get(sk), RTAX_ADVMSS);
+ scp->segsize_loc = dn_dst_metric(__sk_dst_get(sk), RTAX_ADVMSS);
dn_send_conn_conf(sk, allocation);
prepare_to_wait(sk->sk_sleep, &wait, TASK_INTERRUPTIBLE);
@@ -958,7 +958,7 @@ static int __dn_connect(struct sock *sk, struct sockaddr_dn *addr, int addrlen,
sk->sk_route_caps = sk->sk_dst_cache->dev->features;
sock->state = SS_CONNECTING;
scp->state = DN_CI;
- scp->segsize_loc = dst_metric(sk->sk_dst_cache, RTAX_ADVMSS);
+ scp->segsize_loc = dn_dst_metric(sk->sk_dst_cache, RTAX_ADVMSS);
dn_nsp_send_conninit(sk, NSP_CI);
err = -EINPROGRESS;
diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index a7bf03c..ff62012 100644
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -234,15 +234,16 @@ static void dn_dst_update_pmtu(struct dst_entry *dst, u32 mtu)
else
min_mtu -= 21;
- if (dst_metric(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
- if (!(dst_metric_locked(dst, RTAX_MTU))) {
- dst->metrics[RTAX_MTU-1] = mtu;
+ if (dn_dst_metric(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
+ struct dn_route *rt = (struct dn_route *) dst;
+ if (!(dn_dst_metric_locked(dst, RTAX_MTU))) {
+ rt->metrics[RTAX_MTU-1] = mtu;
dst_set_expires(dst, dn_rt_mtu_expires);
}
- if (!(dst_metric_locked(dst, RTAX_ADVMSS))) {
+ if (!(dn_dst_metric_locked(dst, RTAX_ADVMSS))) {
u32 mss = mtu - DN_MAX_NSP_DATA_HEADER;
- if (dst_metric(dst, RTAX_ADVMSS) > mss)
- dst->metrics[RTAX_ADVMSS-1] = mss;
+ if (dn_dst_metric(dst, RTAX_ADVMSS) > mss)
+ rt->metrics[RTAX_ADVMSS-1] = mss;
}
}
}
@@ -788,8 +789,8 @@ static int dn_rt_set_next_hop(struct dn_route *rt, struct dn_fib_res *res)
if (DN_FIB_RES_GW(*res) &&
DN_FIB_RES_NH(*res).nh_scope == RT_SCOPE_LINK)
rt->rt_gateway = DN_FIB_RES_GW(*res);
- memcpy(rt->u.dst.metrics, fi->fib_metrics,
- sizeof(rt->u.dst.metrics));
+ memcpy(rt->metrics, fi->fib_metrics,
+ sizeof(rt->metrics));
}
rt->rt_type = res->type;
@@ -800,13 +801,13 @@ static int dn_rt_set_next_hop(struct dn_route *rt, struct dn_fib_res *res)
rt->u.dst.neighbour = n;
}
- if (dst_metric(&rt->u.dst, RTAX_MTU) == 0 ||
- dst_metric(&rt->u.dst, RTAX_MTU) > rt->u.dst.dev->mtu)
- rt->u.dst.metrics[RTAX_MTU-1] = rt->u.dst.dev->mtu;
- mss = dn_mss_from_pmtu(dev, dst_mtu(&rt->u.dst));
- if (dst_metric(&rt->u.dst, RTAX_ADVMSS) == 0 ||
- dst_metric(&rt->u.dst, RTAX_ADVMSS) > mss)
- rt->u.dst.metrics[RTAX_ADVMSS-1] = mss;
+ if (dn_dst_metric(&rt->u.dst, RTAX_MTU) == 0 ||
+ dn_dst_metric(&rt->u.dst, RTAX_MTU) > rt->u.dst.dev->mtu)
+ rt->metrics[RTAX_MTU-1] = rt->u.dst.dev->mtu;
+ mss = dn_mss_from_pmtu(dev, dn_dst_mtu(&rt->u.dst));
+ if (dn_dst_metric(&rt->u.dst, RTAX_ADVMSS) == 0 ||
+ dn_dst_metric(&rt->u.dst, RTAX_ADVMSS) > mss)
+ rt->metrics[RTAX_ADVMSS-1] = mss;
return 0;
}
@@ -1485,7 +1486,7 @@ static int dn_rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq,
RTA_PUT(skb, RTA_PREFSRC, 2, &rt->rt_local_src);
if (rt->rt_daddr != rt->rt_gateway)
RTA_PUT(skb, RTA_GATEWAY, 2, &rt->rt_gateway);
- if (rtnetlink_put_metrics(skb, rt->u.dst.metrics) < 0)
+ if (rtnetlink_put_metrics(skb, rt->metrics) < 0)
goto rtattr_failure;
expires = rt->u.dst.expires ? rt->u.dst.expires - jiffies : 0;
if (rtnl_put_cacheinfo(skb, &rt->u.dst, 0, 0, 0, expires,
@@ -1712,7 +1713,7 @@ static int dn_rt_cache_seq_show(struct seq_file *seq, void *v)
dn_addr2asc(le16_to_cpu(rt->rt_saddr), buf2),
atomic_read(&rt->u.dst.__refcnt),
rt->u.dst.__use,
- (int) dst_metric(&rt->u.dst, RTAX_RTT));
+ (int) dn_dst_metric(&rt->u.dst, RTAX_RTT));
return 0;
}
--
1.7.0.3
^ permalink raw reply related
* Re: [Bugme-new] [Bug 15571] New: TCP madness - some packets are shunned.
From: Stephen Hemminger @ 2010-03-28 4:26 UTC (permalink / raw)
To: Arnd Hannemann
Cc: Jasen Betts, netdev, bugzilla-daemon, bugme-daemon, Andrew Morton
In-Reply-To: <4BAC733A.1070403@nets.rwth-aachen.de>
On Fri, 26 Mar 2010 09:41:30 +0100
Arnd Hannemann <hannemann@nets.rwth-aachen.de> wrote:
> [re-adding CCs] please reply to all
>
> Am 26.03.2010 06:31, schrieb Jasen Betts:
> > On Thu, Mar 25, 2010 at 04:34:25PM +0100, Arnd Hannemann wrote:
> >> Am 22.03.2010 22:37, schrieb Andrew Morton:
> >>>
> >>> (switched to email. Please respond via emailed reply-to-all, not via the
> >>> bugzilla web interface).
> >>>
> >>> On Thu, 18 Mar 2010 02:46:29 GMT
> >>> bugzilla-daemon@bugzilla.kernel.org wrote:
> >>>
> >>>> http://bugzilla.kernel.org/show_bug.cgi?id=15571
> >>>>
> >>>> URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=53646
> >>>> 2
> >>>> Summary: TCP madness - some packets are shunned.
> >>>> Product: Networking
> >>>> Version: 2.5
> >>>> Kernel Version: 2.6.30
> >>>> Platform: All
> >>>> OS/Version: Linux
> >>>> Tree: Mainline
> >>>> Status: NEW
> >>>> Severity: normal
> >>>> Priority: P1
> >>>> Component: Other
> >>>> AssignedTo: acme@ghostprotocols.net
> >>>> ReportedBy: jasen@treshna.com
> >>>> Regression: No
> >>>>
> >>>>
> >>>> The host http://www.cv-it.com is virtually unreachable with kernel 2.6.26
> >>>> (and later) slow with kernel 2.6.18 and just fine with windows XP.
> >>>>
> >>>> I used telnet to port 80 for testing.
> >>>>
> >>>> it seems to be a TCP issue, as the having the XP machine behind a linux based
> >>>> iptables firewall pc causes no problems, but telnet from the firewall pc itself
> >>>> to port 80 on www.cv-it.com does not work
> >>
> >> For me it seems to be the host is messing up with the window scale option.
> >> Although it claims to support window scaling:
> >> 16:23:17.466592 IP x.x.x.x.51151 > 121.199.32.220.80: Flags [S], seq 2159265664, win 5840, options [mss 1460,sackOK,TS val 8382141 ecr 0,nop,wscale 7], length 0
> >> 16:23:17.761697 IP 121.199.32.220.80 > x.x.x.x.51151: Flags [S.], seq 3910885479, ack 2159265665, win 65535, options [mss 1448,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 8], length 0
> >>
> >> My host (linux 2.6.32) is offering a window of 5888 (46<<7):
> >> 16:23:17.761740 IP x.x.x.x.51151 > 121.199.32.220.80: Flags [.], ack 1, win 46, length 0
> >>
> >> And cv-it.com seems to think there is only a window of 46 ignoring the previously negotiated window scaling:
> >> 16:23:23.066318 IP 121.199.32.220.80 > x.x.x.x.51151: Flags [.], seq 1:47, ack 112, win 65160, length 46
> >>
> >> You can disable window scaling with:
> >> sysctl -w "net.ipv4.tcp_window_scaling=0"
> >>
> >
> > yeah, that works for me.
> >
> > I don't know a lot about this stuff. wikipedia says windows XP does window
> > scaling also, yet it's not a problem with XP only with linux.
>
> This may be pure coincidence that XP "works".
> For instance if XP is only using a window scale of 1 or 2, the effect of
> ignoring the window scale may not be so drastic. However, the problem is:
> once you negotiated the window scale for a connection you must not change
> it and you may actually need a big window for performance reasons.
> So you have to pick a window scale value, so you can express the
> largest window you are going to use.
> In Linux the maximum tcp receive window can be manipulated with the
> "net.ipv4.tcp_rmem" sysctl. (The max is the third value)
> Recent linux kernels use the amount of ram your machine has to calculate
> the default value for this.
>
> >
> >> My host (linux 2.6.32) is offering a window of 5888 (46<<7):
> >> 16:23:17.761740 IP x.x.x.x.51151 > 121.199.32.220.80: Flags [.], ack 1, win 46, length 0
> >
> > so you mean it seems to see '46' as '46' instead of 46<<7 == 5888
The window is also settable on a per route basis as well.
http://lwn.net/Articles/92727/
--
^ permalink raw reply
* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: Herbert Xu @ 2010-03-28 8:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100327.203120.98894145.davem@davemloft.net>
On Sat, Mar 27, 2010 at 08:31:20PM -0700, David Miller wrote:
>
> Finally, we can really move the metrics array into the inetpeer
> entries.
My main question is how do we deal with source-address policy
routing in a host cache?
Thanks,
--
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: UDP path MTU discovery
From: Andi Kleen @ 2010-03-28 8:41 UTC (permalink / raw)
To: David Miller; +Cc: gdt, netdev
In-Reply-To: <20100325.202424.201654947.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Glen Turner <gdt@gdt.id.au>
> Date: Fri, 26 Mar 2010 10:32:31 +1030
>
>> This differs from TCP, where it is the kernel -- and not
>> the application -- which organises retransmission. On
>> receiving a ICMP Fragmentation Needed the kernel can
>> immediately re-probe the path MTU wiht no waiting for
>> an exponential timer to expire.
>
> So the argument is, the kernel TCP does retransmission smart,
> userspace UDP apps do it stupidly, so let's turn off the feature
> instead of fixing userspace.
>
> Right?
>
> Sorry, fix this correctly in the user apps. Putting the
> blame on UDP path MTU discovery is placing it in the
> wrong spot.
It means though that all IPv6 UDP applications essentially have
to implement path mtu discovery support (which is non trivial)
Will be likely a long time until they're all fixed.
Seems like a big hole not considered by the IPv6 designers?
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: UDP path MTU discovery
From: Andi Kleen @ 2010-03-28 8:50 UTC (permalink / raw)
To: Glen Turner; +Cc: netdev
In-Reply-To: <1269561751.2891.8.camel@ilion>
Glen Turner <gdt@gdt.id.au> writes:
> In IPv6 routers do not fragment packets, so there is no work
> around. Transactional servers which use UDP over IPv6 encounter
> exponential backoffs within the application and the client
> abandons the transaction. There is no way for the server to
> know that the packet was lost due to Path MTU Discovery and
> to immediately re-transmit it (without an exponential penalty)
> so that the MTU can be probed again.
You can still turn path mtu discovery off and Linux will
fragment based on the known path MTU (I believe when
the too big fragment gets a icmp back the pmtu gets updated)
However you might lose a few packets in the process until the path MTU
is known, but at least it will stay cached (unless you thrash the
routing cache)
In theory one could probably add some hack in the the kernel UDP code
to hold one packet and retransmit it immediately with fragments when
the ICMP comes in. However that would be quite far in behaviour from
traditional UDP and be considered very ugly. It could also mess up
congestion avoidance schemes done by the application.
Still might be preferable over rewriting zillions of applications?
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [ANNOUNCEMENT] NET: usb: sierra_net.c driver
From: Sergei Shtylyov @ 2010-03-28 10:38 UTC (permalink / raw)
To: Elina Pasheva
Cc: David Brownell, Rory Filer, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb
In-Reply-To: <1269652919.30630.1.camel@Linuxdev3>
Hello.
Elina Pasheva wrote:
> Subject: [ANNOUNCEMENT] NET: usb: sierra_net.c driver
> From: Elina Pasheva <epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8@public.gmane.org>
>
> The following is a new Linux driver which exposes certain models of Sierra
> Wireless modems to the operating system as Network Interface Cards (NICs).
>
> This driver requires a version of the sierra.c driver which supports
> blacklisting to work properly. The blacklist in sierra.c rejects the interfaces
> claimed by sierra_net.c. Likewise, the sierra_net.c driver only accepts
> (i.e. whitelists) the interface(s) used for Direct IP traffic.
> The term "Direct IP" is used within Sierra Wireless to refer to these alternate
> data interfaces. The version of sierra.c which supports blacklisting is
> available from the sierra wireless knowledge base page for older kernels. It is
> also available in Linux kernel starting from version 2.6.31.
>
> This driver works with all Sierra Wireless devices configured with PID=68A3
> like USB305, USB306 provided the corresponding firmware version is I2.0
> (for USB305) or M3.0 (for USB306) and later.
> This driver will not work with earlier firmware versions than the ones shown
> above. In this case the driver will issue an error message indicating
> incompatibility and will not serve the device's DirectIP interface.
>
> Sierra_net.c sits atop a pre-existing Linux driver called usbnet.c.
> A series of hook functions are provided in sierra_net.c which are called by
> usbnet.c in response to a particular condition such as receipt or transmission
> of a data packet. As such, usbnet.c does most of the work of making
> a modem appear to the system as a network device and for properly exchanging
> traffic between the USB subsystem and the Network card interface.
> Sierra_net.c is concerned with managing the data exchanged between the
> so-called Direct-IP interface and the upper layers of the operating system.
>
> The version number of sierra_net.c driver is set to 2.0.
> This patch has been tested on the latest stable kernel-2.6.33.1.
> Signed-off-by: Elina Pasheva <epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Rory Filer <epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8@public.gmane.org>
>
I doubt that it's Rory's email address. :-)
WBR, Sergei
--
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] iwlwifi: range checking issue
From: Dan Carpenter @ 2010-03-28 11:55 UTC (permalink / raw)
To: Zhu Yi
Cc: Reinette Chatre, Intel Linux Wireless, John W. Linville,
Abhijeet Kolekar, Johannes Berg, Wey-Yi Guy, linux-wireless,
netdev, linux-kernel, kernel-janitors
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>
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 54daa38..7d3806a 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -1955,7 +1955,7 @@ static void iwl3945_init_hw_rates(struct iwl_priv *priv,
{
int i;
- for (i = 0; i < IWL_RATE_COUNT; i++) {
+ for (i = 0; i < IWL_RATE_COUNT_LEGACY; i++) {
rates[i].bitrate = iwl3945_rates[i].ieee * 5;
rates[i].hw_value = i; /* Rate scaling will work on indexes */
rates[i].hw_value_short = i;
^ permalink raw reply related
* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: David Miller @ 2010-03-28 12:53 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20100328082250.GA14053@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 28 Mar 2010 16:22:50 +0800
> On Sat, Mar 27, 2010 at 08:31:20PM -0700, David Miller wrote:
>>
>> Finally, we can really move the metrics array into the inetpeer
>> entries.
>
> My main question is how do we deal with source-address policy
> routing in a host cache?
We don't, the same like how we don't handle fully specified
IPSEC policies deciding upon the route.
^ permalink raw reply
* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: Herbert Xu @ 2010-03-28 13:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100328.055312.58421329.davem@davemloft.net>
On Sun, Mar 28, 2010 at 05:53:12AM -0700, David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sun, 28 Mar 2010 16:22:50 +0800
>
> > My main question is how do we deal with source-address policy
> > routing in a host cache?
>
> We don't, the same like how we don't handle fully specified
> IPSEC policies deciding upon the route.
I thought we did handle source-address policy routing for PMTU
messages at least. I just checked ip_rt_frag_needed and it does
if (rth->fl.fl4_dst != daddr ||
rth->fl.fl4_src != skeys[i] ||
rth->rt_dst != daddr ||
rth->rt_src != iph->saddr ||
rth->fl.oif != ikeys[k] ||
rth->fl.iif != 0 ||
dst_metric_locked(&rth->u.dst, RTAX_MTU) ||
!net_eq(dev_net(rth->u.dst.dev), net) ||
rt_is_expired(rth))
continue;
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: David Miller @ 2010-03-28 13:40 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20100328131112.GA15984@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 28 Mar 2010 21:11:12 +0800
> On Sun, Mar 28, 2010 at 05:53:12AM -0700, David Miller wrote:
>> From: Herbert Xu <herbert@gondor.apana.org.au>
>> Date: Sun, 28 Mar 2010 16:22:50 +0800
>>
>> > My main question is how do we deal with source-address policy
>> > routing in a host cache?
>>
>> We don't, the same like how we don't handle fully specified
>> IPSEC policies deciding upon the route.
>
> I thought we did handle source-address policy routing for PMTU
> messages at least. I just checked ip_rt_frag_needed and it does
Same for all the other metrics at the TCP level.
I guess this is the decision we have to make, what does
"host level" metrics mean for us if we decide to move
things into the inetpeer cache.
^ 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
* 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: [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
* [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
* [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-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
* 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
* 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: [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: 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
* [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
* [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
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