* Resend: [PATCH] TCP Early Retransmit: reduce required dupacks for triggering fast retrans
From: Christian Samsel @ 2009-09-22 8:59 UTC (permalink / raw)
To: netdev
This patch implements draft-ietf-tcpm-early-rexmt. The early retransmit
mechanism allows the transport to reduce the number of duplicate
acknowledgments required to trigger a fast retransmission in case we
don't expect enough dupacks, (e.g. because there are not enough
packets inflight and nothing to send). This allows the transport to use
fast retransmit to recover packet losses that would otherwise require
a lengthy retransmission timeout.
See: http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01
Signed-off-by: Christian Samsel <christian.samsel@rwth-aachen.de>
---
net/ipv4/tcp_input.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index af6d6fa..c0cc4fd 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2913,6 +2913,7 @@ static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
int do_lost = is_dupack || ((flag & FLAG_DATA_SACKED) &&
(tcp_fackets_out(tp) > tp->reordering));
int fast_rexmit = 0, mib_idx;
+ u32 in_flight;
if (WARN_ON(!tp->packets_out && tp->sacked_out))
tp->sacked_out = 0;
@@ -3062,6 +3063,21 @@ static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
if (do_lost || (tcp_is_fack(tp) && tcp_head_timedout(sk)))
tcp_update_scoreboard(sk, fast_rexmit);
tcp_cwnd_down(sk, flag);
+
+
+ /* draft-ietf-tcpm-early-rexmt: lowers dup ack threshold to prevent rto
+ * in case we don't expect enough dup ack. if number of outstanding
+ * packets is less than four and there is either no unsent data ready
+ * for transmission or the advertised window does not permit new
+ * segments.
+ */
+ in_flight = tcp_packets_in_flight(tp);
+ if ( in_flight < 4 && (skb_queue_empty(&sk->sk_write_queue) ||
+ tcp_may_send_now(sk) == 0) )
+ tp->reordering = in_flight - 1;
+ else if (tp->reordering != sysctl_tcp_reordering)
+ tp->reordering = sysctl_tcp_reordering;
+
tcp_xmit_retransmit_queue(sk);
}
--
1.6.4.1
^ permalink raw reply related
* [PATCH][RESEND 2] IPv6: 6rd tunnel mode
From: Alexandre Cassen @ 2009-09-22 8:51 UTC (permalink / raw)
To: netdev
This patch add support to 6rd tunnel mode currently targetting
standard track at the IETF.
Patch history :
* http://patchwork.ozlabs.org/patch/26870/
* http://patchwork.ozlabs.org/patch/34026/
IPv6 rapid deployment (RFC5569) builds upon mechanisms of 6to4 (RFC3056)
to enable a service provider to rapidly deploy IPv6 unicast service
to IPv4 sites to which it provides customer premise equipment. Like
6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to
transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service
provider uses an IPv6 prefix of its own in place of the fixed 6to4
prefix.
Signed-off-by: Alexandre Cassen <acassen@freebox.fr>
---
include/linux/if_tunnel.h | 10 +++++
include/net/ipip.h | 2 +
net/ipv6/Kconfig | 13 +++++++
net/ipv6/sit.c | 84 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 109 insertions(+), 0 deletions(-)
diff --git a/include/linux/if_tunnel.h b/include/linux/if_tunnel.h
index 5eb9b0f..0d44376 100644
--- a/include/linux/if_tunnel.h
+++ b/include/linux/if_tunnel.h
@@ -15,6 +15,10 @@
#define SIOCADDPRL (SIOCDEVPRIVATE + 5)
#define SIOCDELPRL (SIOCDEVPRIVATE + 6)
#define SIOCCHGPRL (SIOCDEVPRIVATE + 7)
+#define SIOCGET6RD (SIOCDEVPRIVATE + 8)
+#define SIOCADD6RD (SIOCDEVPRIVATE + 9)
+#define SIOCDEL6RD (SIOCDEVPRIVATE + 10)
+#define SIOCCHG6RD (SIOCDEVPRIVATE + 11)
#define GRE_CSUM __cpu_to_be16(0x8000)
#define GRE_ROUTING __cpu_to_be16(0x4000)
@@ -51,6 +55,12 @@ struct ip_tunnel_prl {
/* PRL flags */
#define PRL_DEFAULT 0x0001
+/* 6RD parms */
+struct ip_tunnel_6rd {
+ struct in6_addr addr;
+ __u8 prefixlen;
+};
+
enum
{
IFLA_GRE_UNSPEC,
diff --git a/include/net/ipip.h b/include/net/ipip.h
index 5d3036f..fa92c41 100644
--- a/include/net/ipip.h
+++ b/include/net/ipip.h
@@ -26,6 +26,8 @@ struct ip_tunnel
struct ip_tunnel_prl_entry *prl; /* potential router list */
unsigned int prl_count; /* # of entries in PRL */
+
+ struct ip_tunnel_6rd ip6rd_prefix; /* 6RD SP prefix */
};
/* ISATAP: default interval between RS in secondy */
diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
index ead6c7a..78a565b 100644
--- a/net/ipv6/Kconfig
+++ b/net/ipv6/Kconfig
@@ -170,6 +170,19 @@ config IPV6_SIT
Saying M here will produce a module called sit. If unsure, say Y.
+config IPV6_SIT_6RD
+ bool "IPv6: 6rd tunnel mode (EXPERIMENTAL)"
+ depends on IPV6_SIT && EXPERIMENTAL
+ default n
+ ---help---
+ IPv6 rapid deployment (RFC5569) builds upon mechanisms of 6to4 (RFC3056)
+ to enable a service provider to rapidly deploy IPv6 unicast service
+ to IPv4 sites to which it provides customer premise equipment. Like
+ 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to
+ transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service
+ provider uses an IPv6 prefix of its own in place of the fixed 6to4
+ prefix.
+
config IPV6_NDISC_NODETYPE
bool
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 0ae4f64..034acdc 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -604,6 +604,30 @@ static inline __be32 try_6to4(struct in6_addr *v6dst)
return dst;
}
+#ifdef CONFIG_IPV6_SIT_6RD
+/* Returns the embedded IPv4 address if the IPv6 address comes from
+ 6rd rule */
+
+static inline __be32 try_6rd(struct in6_addr *addr, u8 prefix_len, struct in6_addr *v6dst)
+{
+ __be32 dst = 0;
+
+ /* isolate addr according to mask */
+ if (ipv6_prefix_equal(v6dst, addr, prefix_len)) {
+ unsigned int d32_off, bits;
+
+ d32_off = prefix_len >> 5;
+ bits = (prefix_len & 0x1f);
+
+ dst = (ntohl(v6dst->s6_addr32[d32_off]) << bits);
+ if (bits)
+ dst |= ntohl(v6dst->s6_addr32[d32_off + 1]) >> (32 - bits);
+ dst = htonl(dst);
+ }
+ return dst;
+}
+#endif
+
/*
* This function assumes it is being called from dev_queue_xmit()
* and that skb is filled properly by that function.
@@ -657,6 +681,13 @@ static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
goto tx_error;
}
+#ifdef CONFIG_IPV6_SIT_6RD
+ if (!dst && tunnel->ip6rd_prefix.prefixlen)
+ dst = try_6rd(&tunnel->ip6rd_prefix.addr,
+ tunnel->ip6rd_prefix.prefixlen,
+ &iph6->daddr);
+ else
+#endif
if (!dst)
dst = try_6to4(&iph6->daddr);
@@ -848,6 +879,9 @@ ipip6_tunnel_ioctl (struct net_device *dev, struct ifreq *ifr, int cmd)
int err = 0;
struct ip_tunnel_parm p;
struct ip_tunnel_prl prl;
+#ifdef CONFIG_IPV6_SIT_6RD
+ struct ip_tunnel_6rd ip6rd;
+#endif
struct ip_tunnel *t;
struct net *net = dev_net(dev);
struct sit_net *sitn = net_generic(net, sit_net_id);
@@ -987,6 +1021,56 @@ ipip6_tunnel_ioctl (struct net_device *dev, struct ifreq *ifr, int cmd)
netdev_state_change(dev);
break;
+#ifdef CONFIG_IPV6_SIT_6RD
+ case SIOCGET6RD:
+ err = -EINVAL;
+ if (dev == sitn->fb_tunnel_dev)
+ goto done;
+ err = -ENOENT;
+ if (!(t = netdev_priv(dev)))
+ goto done;
+ memcpy(&ip6rd, &t->ip6rd_prefix, sizeof(ip6rd));
+ if (copy_to_user(ifr->ifr_ifru.ifru_data, &ip6rd, sizeof(ip6rd)))
+ err = -EFAULT;
+ else
+ err = 0;
+ break;
+
+ case SIOCADD6RD:
+ case SIOCDEL6RD:
+ case SIOCCHG6RD:
+ err = -EPERM;
+ if (!capable(CAP_NET_ADMIN))
+ goto done;
+ err = -EINVAL;
+ if (dev == sitn->fb_tunnel_dev)
+ goto done;
+ err = -EFAULT;
+ if (copy_from_user(&ip6rd, ifr->ifr_ifru.ifru_data, sizeof(ip6rd)))
+ goto done;
+ err = -ENOENT;
+ if (!(t = netdev_priv(dev)))
+ goto done;
+
+ err = 0;
+ switch (cmd) {
+ case SIOCDEL6RD:
+ memset(&t->ip6rd_prefix, 0, sizeof(ip6rd));
+ break;
+ case SIOCADD6RD:
+ case SIOCCHG6RD:
+ if (ip6rd.prefixlen >= 95) {
+ err = -EINVAL;
+ goto done;
+ }
+ ipv6_addr_copy(&t->ip6rd_prefix.addr, &ip6rd.addr);
+ t->ip6rd_prefix.prefixlen = ip6rd.prefixlen;
+ break;
+ }
+ netdev_state_change(dev);
+ break;
+#endif
+
default:
err = -EINVAL;
}
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 12/13] TProxy: added IPv6 support to the socket match
From: Jan Engelhardt @ 2009-09-22 8:33 UTC (permalink / raw)
To: Balazs Scheidler; +Cc: netfilter-devel, netdev
In-Reply-To: <1253548005.12519.12.camel@bzorp.balabit>
On Monday 2009-08-24 14:52, Balazs Scheidler wrote:
>+static bool
>+socket_mt6_v1(const struct sk_buff *skb, const struct xt_match_param *par)
>+{
>+ struct ipv6hdr *iph = ipv6_hdr(skb);
>+ struct udphdr _hdr, *hp = NULL;
>+ struct sock *sk;
>+ struct in6_addr *daddr, *saddr;
>+ __be16 dport, sport;
>+ int thoff;
>+ u8 tproto;
>+ const struct xt_socket_mtinfo1 *info = (struct xt_socket_mtinfo1 *) par->matchinfo;
>+
>+ tproto = ipv6_find_hdr(skb, &thoff, -1, NULL);
>+ if (tproto < 0) {
>+ pr_debug("socket match: Unable to find transport header in IPv6 packet, dropping\n");
>+ return NF_DROP;
>+ }
>+
>+ if (tproto == IPPROTO_UDP || tproto == IPPROTO_TCP) {
The tabbing seems off (also noticed this in other patches,
pcregrep for '^ {8}' )
^ permalink raw reply
* Re: [PATCH 10/13] TProxy: added IPv6 socket lookup function to nf_tproxy_core
From: Jan Engelhardt @ 2009-09-22 8:30 UTC (permalink / raw)
To: Balazs Scheidler; +Cc: netfilter-devel, netdev
In-Reply-To: <1253548005.12519.10.camel@bzorp.balabit>
On Monday 2009-08-24 14:51, Balazs Scheidler wrote:
>+ case NFT_LOOKUP_LISTENER:
>+ sk = inet6_lookup_listener(net, &tcp_hashinfo,
>+ daddr, ntohs(dport),
>+ in->ifindex);
>+
>+ /* NOTE: we return listeners even if bound to
>+ * 0.0.0.0, those are filtered out in
s/0.0.0.0/::/g :-)
^ permalink raw reply
* Re: [PATCH][RESEND] IPv6: 6rd tunnel mode
From: Alexandre Cassen @ 2009-09-22 6:59 UTC (permalink / raw)
To: Brian Haley; +Cc: netdev
In-Reply-To: <4AB838F1.1090704@hp.com>
Hi Brian,
On Mon, 2009-09-21 at 22:39 -0400, Brian Haley wrote:
> Hi Alexandre,
>
> Alexandre Cassen wrote:
> > This patch add support to 6rd tunnel mode currently targetting
> > standard track at the IETF.
> >
> > IPv6 rapid deployment (RFC5569) builds upon mechanisms of 6to4 (RFC3056)
> > to enable a service provider to rapidly deploy IPv6 unicast service
> > to IPv4 sites to which it provides customer premise equipment. Like
> > 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to
> > transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service
> > provider uses an IPv6 prefix of its own in place of the fixed 6to4
> > prefix.
>
> I couldn't find RFC 5569 (delayed due to IPR rights?), although I did find
> the latest 6rd draft, -03. It was showing as Informational, not Standards
> track, is that right? Just curious.
In fact there is currently two draft :
1) https://datatracker.ietf.org/idtracker/draft-despres-6rd/
This draft is targeting informational RFC as an independent
submission. It is currently queued and has been delayed since may for
IPR.
2) http://tools.ietf.org/html/draft-townsley-ipv6-6rd-01
This draft is targeting standard track so work is in progress here.
A good sum up has been done by Mark Townsley at last IETF meeting :
http://www.ietf.org/proceedings/75/slides/dhc-4.pdf
> > + case SIOCADD6RD:
> > + case SIOCCHG6RD:
> > + if (ip6rd.prefixlen >= 95) {
> > + err = -EINVAL;
> > + goto done;
> > + }
> > + t->ip6rd_prefix.addr = ip6rd.addr;
>
> ipv6_addr_copy(&t->ip6rd_prefix.addr, &ip6rd.addr); is the preferred way to
> copy the address.
agreed. will fix and resend.
regs,
Alexandre
^ permalink raw reply
* Re: [PATCH 02/13] TProxy: add lookup type checks for UDP in nf_tproxy_get_sock_v4()
From: Balazs Scheidler @ 2009-09-22 6:40 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter-devel, netdev
In-Reply-To: <alpine.LSU.2.00.0909212320150.31023@obet.zrqbmnf.qr>
On Mon, 2009-09-21 at 23:20 +0200, Jan Engelhardt wrote:
> On Saturday 2009-08-15 14:01, Balazs Scheidler wrote:
>
> >+ case IPPROTO_UDP:
> >+ sk = udp4_lib_lookup(net, saddr, sport, daddr, dport,
> >+ in->ifindex);
>
> You might want to add IPPROTO_UDPLITE in all places.
Well, I preferred not to add those, as I'm unable to test it, and I'd
prefer to submit a patch that really works for UDP and TCP at the
minimum. Further protocols (like SCTP) should be added later IMHO.
--
Bazsi
^ permalink raw reply
* Re: [PATCH 13/13] TProxy: use the interface primary IP address as a default value for --on-ip
From: Balazs Scheidler @ 2009-09-22 6:38 UTC (permalink / raw)
To: Brian Haley; +Cc: netfilter-devel, netdev
In-Reply-To: <4AB7BF47.2030404@hp.com>
On Mon, 2009-09-21 at 14:00 -0400, Brian Haley wrote:
> Balazs Scheidler wrote:
> > #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> > +
> > +static inline const struct in6_addr *
> > +tproxy_laddr6(struct sk_buff *skb, const struct in6_addr *user_laddr, const struct in6_addr *daddr)
> > +{
> > + struct inet6_dev *indev;
> > + struct inet6_ifaddr *ifa;
> > + struct in6_addr *laddr;
> > +
> > + if (!ipv6_addr_any(user_laddr))
> > + return user_laddr;
> > +
> > + laddr = NULL;
> > + rcu_read_lock();
> > + indev = __in6_dev_get(skb->dev);
> > + if (indev && (ifa = indev->addr_list)) {
> > + laddr = &ifa->addr;
> > + }
> > + rcu_read_unlock();
> > +
> > + return laddr ? laddr : daddr;
> > +}
>
> You should call ipv6_dev_get_saddr() to get a source address based on the target
> destination address.
Thanks for this hint, however this is not selecting a source address for
a given destination, rather it selects the address where tproxy is
redirecting the connection in case the user specified no --on-ip
parameter.
e.g.
ip6tables -A PREROUTING -p tcp --dport 80 -j TPROXY --on-port 50080
This should redirect the connection to the primary IP address of the
incoming interface. In fact I spent 2 hours to figure out how to find
the proper address, and at the end I used the first IP address
configured to the interface, seeing that those addresses are sorted in
'scope' order, e.g. link-local and site-local addresses are at the end
of the list, thus the front should be ok.
Since I'm not that much into IPv6, I'd appreciate some help, is
ipv6_dev_get_saddr(client_ip_address) indeed the best solution here?
--
Bazsi
^ permalink raw reply
* Re: [PATCH 12/13] TProxy: added IPv6 support to the socket match
From: Balazs Scheidler @ 2009-09-22 6:33 UTC (permalink / raw)
To: Brian Haley; +Cc: netfilter-devel, netdev
In-Reply-To: <4AB7BEF8.5050800@hp.com>
On Mon, 2009-09-21 at 13:59 -0400, Brian Haley wrote:
> Balazs Scheidler wrote:
> > +static bool
> > +socket_mt6_v1(const struct sk_buff *skb, const struct xt_match_param *par)
> > +{
> > + struct ipv6hdr *iph = ipv6_hdr(skb);
> > + struct udphdr _hdr, *hp = NULL;
> > + struct sock *sk;
> > + struct in6_addr *daddr, *saddr;
> > + __be16 dport, sport;
> > + int thoff;
> > + u8 tproto;
> > + const struct xt_socket_mtinfo1 *info = (struct xt_socket_mtinfo1 *) par->matchinfo;
> > +
> > + tproto = ipv6_find_hdr(skb, &thoff, -1, NULL);
> > + if (tproto < 0) {
> > + pr_debug("socket match: Unable to find transport header in IPv6 packet, dropping\n");
> > + return NF_DROP;
> > + }
> > +
> > + if (tproto == IPPROTO_UDP || tproto == IPPROTO_TCP) {
> > + hp = skb_header_pointer(skb, thoff,
> > + sizeof(_hdr), &_hdr);
> > + if (hp == NULL)
> > + return false;
> > +
> > + saddr = &iph->saddr;
> > + sport = hp->source;
> > + daddr = &iph->daddr;
> > + dport = hp->dest;
> > +
> > + } else if (tproto == IPPROTO_ICMP) {
> > + if (extract_icmp6_fields(skb, thoff, &tproto, &saddr, &daddr,
> > + &sport, &dport))
> > + return false;
> > + } else {
> > + return false;
> > + }
>
> Shouldn't this be IPPROTO_ICMPV6?
Yeah, thanks for spotting this. I'm going to have to add ICMP checks to
my test program, or at least retest that functionality manually.
--
Bazsi
^ permalink raw reply
* Re: [PATCH 1/2] pktgen: check for link down
From: Stephen Hemminger @ 2009-09-22 5:55 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, Robert Olsson, Jesper Dangaard Brouer, netdev
In-Reply-To: <20090919221844.114e2e23@nehalam>
On Sat, 19 Sep 2009 22:18:44 -0700
Stephen Hemminger <shemminger@vyatta.com> wrote:
> If cable is pulled, pktgen shouldn't continue slamming packets into the
> device.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> --- a/net/core/pktgen.c 2009-09-19 11:20:55.546463176 -0700
> +++ b/net/core/pktgen.c 2009-09-19 11:22:44.810509240 -0700
> @@ -1959,7 +1959,7 @@ static int pktgen_setup_dev(struct pktge
> if (odev->type != ARPHRD_ETHER) {
> printk(KERN_ERR "pktgen: not an ethernet device: \"%s\"\n", ifname);
> err = -EINVAL;
> - } else if (!netif_running(odev)) {
> + } else if (!netif_running(odev) || !netif_carrier_ok(odev)) {
> printk(KERN_ERR "pktgen: device is down: \"%s\"\n", ifname);
> err = -ENETDOWN;
> } else {
> @@ -3410,7 +3410,7 @@ static void pktgen_xmit(struct pktgen_de
> /* Did we saturate the queue already? */
> if (netif_tx_queue_stopped(txq) || netif_tx_queue_frozen(txq)) {
> /* If device is down, then all queues are permnantly frozen */
> - if (netif_running(odev))
> + if (netif_running(odev) && netif_carrier_ok(odev))
> idle(pkt_dev);
> else
> pktgen_stop_device(pkt_dev);
You can hold off on these two patches, I have better version
which fixes some other issues. But testing time is limited this week.
^ permalink raw reply
* Re: [PATCH V3 2/2] ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface
From: David Miller @ 2009-09-22 5:39 UTC (permalink / raw)
To: haas; +Cc: netdev, greg, wg, socketcan-core
In-Reply-To: <20090916120420.30391.40000.stgit@localhost.localdomain>
From: Sebastian Haas <haas@ems-wuensche.com>
Date: Wed, 16 Sep 2009 14:04:20 +0200
> This patch adds support for one channel CAN/USB interace CPC-USB/ARM7 from
> EMS Dr. Thomas Wuensche (http://www.ems-wuensche.com).
>
> Signed-off-by: Sebastian Haas <haas@ems-wuensche.com>
Applied.
^ permalink raw reply
* Re: [PATCH V3 1/2] cpc-usb: Removed driver from staging tree
From: David Miller @ 2009-09-22 5:39 UTC (permalink / raw)
To: haas; +Cc: netdev, greg, wg, socketcan-core
In-Reply-To: <20090916120415.30391.69148.stgit@localhost.localdomain>
From: Sebastian Haas <haas@ems-wuensche.com>
Date: Wed, 16 Sep 2009 14:04:15 +0200
> This patch prepares replacing the staging driver cpc-usb with the new
> developed ems_usb CAN driver.
>
> Signed-off-by: Sebastian Haas <haas@ems-wuensche.com>
> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Applied.
^ permalink raw reply
* Re: [PATCH] cpmac: fix compilation errors against undeclared BUS_ID_SIZE
From: David Miller @ 2009-09-22 5:38 UTC (permalink / raw)
To: florian; +Cc: netdev, ralf, linux-mips
In-Reply-To: <200909191243.09166.florian@openwrt.org>
From: Florian Fainelli <florian@openwrt.org>
Date: Sat, 19 Sep 2009 12:43:08 +0200
> David,
>
> Ping ? This fixes a build failure. Thank you very much !
Applied, thanks.
^ permalink raw reply
* Re: [patch 1/1] net: fix CONFIG_NET=n build on sparc64
From: David Miller @ 2009-09-22 5:38 UTC (permalink / raw)
To: akpm; +Cc: netdev
In-Reply-To: <200909181952.n8IJqEdD024614@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Fri, 18 Sep 2009 12:52:13 -0700
> From: Andrew Morton <akpm@linux-foundation.org>
>
> sparc64 allnoconfig:
>
> arch/sparc/kernel/built-in.o(.text+0x134e0): In function `sys32_recvfrom':
> : undefined reference to `compat_sys_recvfrom'
> arch/sparc/kernel/built-in.o(.text+0x134e4): In function `sys32_recvfrom':
> : undefined reference to `compat_sys_recvfrom'
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 3/3] ixgbe: move rx queue RSC configuration to a separate function
From: David Miller @ 2009-09-22 5:37 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, shannon.nelson, peter.p.waskiewicz.jr,
donald.c.skidmore
In-Reply-To: <20090918194627.28898.75773.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 18 Sep 2009 12:46:27 -0700
> From: Nelson, Shannon <shannon.nelson@intel.com>
>
> Shorten ixgbe_configure_rx() and lessen indent depth.
>
> Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/3] ixgbe: Allow tx itr specific settings
From: David Miller @ 2009-09-22 5:37 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, shannon.nelson, peter.p.waskiewicz.jr
In-Reply-To: <20090918194606.28898.37888.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 18 Sep 2009 12:46:06 -0700
> From: Nelson, Shannon <shannon.nelson@intel.com>
>
> Allow the user to set Tx specific itr values. This only makes sense
> when there are separate vectors for Tx and Rx. When the queues are
> doubled up RxTx on the vectors, we still only use the rx itr value.
>
> Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/3] ixgbe: fix sfp_timer clean up in ixgbe_down
From: David Miller @ 2009-09-22 5:37 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, shannon.nelson, donald.c.skidmore,
peter.p.waskiewicz.jr
In-Reply-To: <20090918194533.28898.49436.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 18 Sep 2009 12:45:43 -0700
> From: Don Skidmore <donald.c.skidmore@intel.com>
>
> We weren't stoping the sfp_timer after the device was brought down.
> This patch properly cleans up.
>
> Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] igb: resolve namespacecheck warning for igb_hash_mc_addr
From: David Miller @ 2009-09-22 5:37 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20090918005219.25329.94906.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 Sep 2009 17:52:29 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This patch resolves a warning seen when doing namespace checking via
> "make namespacecheck"
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [RFC] skb align patch
From: David Miller @ 2009-09-22 5:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, jesse.brandeburg, hawk, netdev
In-Reply-To: <4AB84295.3050509@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 22 Sep 2009 05:20:53 +0200
> Oh I see, you want to optimize the rx (NIC has to do a DMA to write
> packet into host memory and this DMA could be a read /modify/write
> if address is not aligned, instead of a pure write), while I tried
> to align skb to optimize the pktgen tx (NIC has to do a DMA to read
> packet from host), and align the skb had no effect.
This is a problem with these kinds of changes.
This patch from Stephen came out of a presentation and discussion
at netconf where the Intel folks showed that if they did a combination
of things it improved NUMA forwarding numbers a lot.
So you couldn't just do NUMA spreading of RX queue memory, or just
do this ALIGN patch, or just eliminate the false sharing from
statistics updates.
You had to do all three to start seeing forwarding rates go up.
So don't worry, this is getting us somewhere to where improvement
shows, but individually each change won't trigger it.
The alignment in this patch is a real big deal for 64 byte forwarding
tests, where the entire packet is a whole PCI-E cacheline. But not
if it isn't aligned properly.
^ permalink raw reply
* Re: [RFC] skb align patch
From: Stephen Hemminger @ 2009-09-22 5:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jesse Brandeburg, Jesper Dangaard Brouer, netdev
In-Reply-To: <4AB84295.3050509@gmail.com>
On Tue, 22 Sep 2009 05:20:53 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Stephen Hemminger a écrit :
> > On Mon, 21 Sep 2009 08:13:20 +0200
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> >> Stephen Hemminger a écrit :
> >>> Based on the Intel suggestion that PCI-express overhead is
> >>> a significant cost.
> >>>
> >>> Would people doing performance please measure the impact of
> >>> changing SKB alignment (64 bit only).
> >> I had this idea some time ago when I hit a limit on bnx2 adapter
> >> (Giga bit link, BCM5708S), with small packets. pktgen was able
> >> to send ~500 Mbps 'only', or 700kps if I remember well.
> >> So I tried to align the pktgen build packet to a cache line,
> >> it gave no difference at all, but it was on a 32 bit kernel.
> >> (Thus my patch was for pktgen only, not a generic one as yours)
> >>
> >> Could you elaborate why this change could be useful on 64bit ?
> >>
> >
> > It is useful on all architecture where unaligned CPU access is
> > relatively cheap.
> >
> > The issue is that a unaligned DMA requires a read/modify/write
> > cache line access versus just a write access. I am not a bus
> > expert, but writes are probably more pipelined as well.
> >
>
> Oh I see, you want to optimize the rx (NIC has to do a DMA
> to write packet into host memory and this DMA could be a read
> /modify/write if address is not aligned, instead of a pure write),
> while I tried to align skb to optimize the pktgen tx
> (NIC has to do a DMA to read packet from host), and align the skb
> had no effect.
>
> Maybe we should separate the rx/tx, and try your idea only
> for skb allocated for rx.
>
> Also/Or we might try
> __builtin_prefetch (addr, 0, 0);
> to instruct cpu to commit to memory cache lines that are
> going to be modified by NIC.
Don't think it matters whether RX buffer has to read/modify/write
from cpu cache or memory on modern cache snooping architecures.
The cost is the PCI traffic.
--
^ permalink raw reply
* Re: [RFC] skb align patch
From: Eric Dumazet @ 2009-09-22 3:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jesse Brandeburg, Jesper Dangaard Brouer, netdev
In-Reply-To: <20090921213011.704e0594@nehalam>
Stephen Hemminger a écrit :
> On Mon, 21 Sep 2009 08:13:20 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> Stephen Hemminger a écrit :
>>> Based on the Intel suggestion that PCI-express overhead is
>>> a significant cost.
>>>
>>> Would people doing performance please measure the impact of
>>> changing SKB alignment (64 bit only).
>> I had this idea some time ago when I hit a limit on bnx2 adapter
>> (Giga bit link, BCM5708S), with small packets. pktgen was able
>> to send ~500 Mbps 'only', or 700kps if I remember well.
>> So I tried to align the pktgen build packet to a cache line,
>> it gave no difference at all, but it was on a 32 bit kernel.
>> (Thus my patch was for pktgen only, not a generic one as yours)
>>
>> Could you elaborate why this change could be useful on 64bit ?
>>
>
> It is useful on all architecture where unaligned CPU access is
> relatively cheap.
>
> The issue is that a unaligned DMA requires a read/modify/write
> cache line access versus just a write access. I am not a bus
> expert, but writes are probably more pipelined as well.
>
Oh I see, you want to optimize the rx (NIC has to do a DMA
to write packet into host memory and this DMA could be a read
/modify/write if address is not aligned, instead of a pure write),
while I tried to align skb to optimize the pktgen tx
(NIC has to do a DMA to read packet from host), and align the skb
had no effect.
Maybe we should separate the rx/tx, and try your idea only
for skb allocated for rx.
Also/Or we might try
__builtin_prefetch (addr, 0, 0);
to instruct cpu to commit to memory cache lines that are
going to be modified by NIC.
^ permalink raw reply
* igb VF allocation with quirk_i82576_sriov
From: Chris Wright @ 2009-09-22 5:19 UTC (permalink / raw)
To: John Ronciak; +Cc: netdev, e1000-devel
Is this known to work? During recent virt testing for upcoming Fedora 12,
a box w/out SR-IOV support in BIOS was using quirk to create VF BAR space,
VF allocation worked enough to assign a device to the guest, but igbvf
was not actually functioning properly in the guest.
Is it worth debugging this further, or is it already a known issue?
thanks,
-chris
^ permalink raw reply
* Re: bugfix: wireless bug causing working setups to loose net connectivity
From: John W. Linville @ 2009-09-22 4:24 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: Johannes Berg, netdev
In-Reply-To: <200909212035.50592.a.miskiewicz@gmail.com>
On Mon, Sep 21, 2009 at 08:35:50PM +0200, Arkadiusz Miskiewicz wrote:
>
> Could
> http://marc.info/?l=linux-wireless&m=125323296617306&w=2
> be merged without waiting for separate wireless pull request?
>
> Currently previously working setups are no longer able to connect to AP (in my
> case WPA2PSK via wpasupplicant).
>
> AFAIK there was some kind of policy where bugfixes that break basic
> functionality are supposed to be merged fast to allow to actually use and test
> git kernel.
I'll make sure to include this in the next pull request, probably
tomorrow. Sorry, I'm too tired tonight. FWIW, I'm traveling ATM...
Hth!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [RFC] skb align patch
From: Stephen Hemminger @ 2009-09-22 4:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jesse Brandeburg, Jesper Dangaard Brouer, netdev
In-Reply-To: <4AB71980.4020208@gmail.com>
On Mon, 21 Sep 2009 08:13:20 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Stephen Hemminger a écrit :
> > Based on the Intel suggestion that PCI-express overhead is
> > a significant cost.
> >
> > Would people doing performance please measure the impact of
> > changing SKB alignment (64 bit only).
>
> I had this idea some time ago when I hit a limit on bnx2 adapter
> (Giga bit link, BCM5708S), with small packets. pktgen was able
> to send ~500 Mbps 'only', or 700kps if I remember well.
> So I tried to align the pktgen build packet to a cache line,
> it gave no difference at all, but it was on a 32 bit kernel.
> (Thus my patch was for pktgen only, not a generic one as yours)
>
> Could you elaborate why this change could be useful on 64bit ?
>
It is useful on all architecture where unaligned CPU access is
relatively cheap.
The issue is that a unaligned DMA requires a read/modify/write
cache line access versus just a write access. I am not a bus
expert, but writes are probably more pipelined as well.
--
^ permalink raw reply
* Re: [PATCH] sky2: Set SKY2_HW_RAM_BUFFER in sky2_init
From: Stephen Hemminger @ 2009-09-22 2:50 UTC (permalink / raw)
To: Mike McCormack, David Miller; +Cc: netdev
In-Reply-To: <4AB788F4.90503@ring3k.org>
On Mon, 21 Sep 2009 23:08:52 +0900
Mike McCormack <mikem@ring3k.org> wrote:
> The SKY2_HW_RAM_BUFFER bit in hw->flags was checked in sky2_mac_init(),
> before being set later in sky2_up().
>
> Setting SKY2_HW_RAM_BUFFER in sky2_init() where other hw->flags are set
> should avoid this problem recurring.
>
> Signed-off-by: Mike McCormack <mikem@ring3k.org>
> ---
> drivers/net/sky2.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> index 4bb52e9..68d256b 100644
> --- a/drivers/net/sky2.c
> +++ b/drivers/net/sky2.c
> @@ -1497,7 +1497,6 @@ static int sky2_up(struct net_device *dev)
> if (ramsize > 0) {
> u32 rxspace;
>
> - hw->flags |= SKY2_HW_RAM_BUFFER;
> pr_debug(PFX "%s: ram buffer %dK\n", dev->name, ramsize);
> if (ramsize < 16)
> rxspace = ramsize / 2;
> @@ -2926,6 +2925,9 @@ static int __devinit sky2_init(struct sky2_hw *hw)
> ++hw->ports;
> }
>
> + if (sky2_read8(hw, B2_E_0))
> + hw->flags |= SKY2_HW_RAM_BUFFER;
> +
> return 0;
> }
>
This should go to stable tree as well.
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
--
^ permalink raw reply
* Re: [PATCH][RESEND] IPv6: 6rd tunnel mode
From: Brian Haley @ 2009-09-22 2:39 UTC (permalink / raw)
To: Alexandre Cassen; +Cc: netdev
In-Reply-To: <20090922003956.GA19947@lnxos.staff.proxad.net>
Hi Alexandre,
Alexandre Cassen wrote:
> This patch add support to 6rd tunnel mode currently targetting
> standard track at the IETF.
>
> IPv6 rapid deployment (RFC5569) builds upon mechanisms of 6to4 (RFC3056)
> to enable a service provider to rapidly deploy IPv6 unicast service
> to IPv4 sites to which it provides customer premise equipment. Like
> 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to
> transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service
> provider uses an IPv6 prefix of its own in place of the fixed 6to4
> prefix.
I couldn't find RFC 5569 (delayed due to IPR rights?), although I did find
the latest 6rd draft, -03. It was showing as Informational, not Standards
track, is that right? Just curious.
> + case SIOCADD6RD:
> + case SIOCCHG6RD:
> + if (ip6rd.prefixlen >= 95) {
> + err = -EINVAL;
> + goto done;
> + }
> + t->ip6rd_prefix.addr = ip6rd.addr;
ipv6_addr_copy(&t->ip6rd_prefix.addr, &ip6rd.addr); is the preferred way to
copy the address.
-Brian
^ 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