* [PATCH net-next] packet: fix broken build.
From: Rami Rosen @ 2012-08-23 12:55 UTC (permalink / raw)
To: davem@davemloft.net, netdev@vger.kernel.org
Cc: xemul@parallels.com, edumazet@google.com
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
This patch fixes a broken build due to a missing header:
...
CC net/ipv4/proc.o
In file included from include/net/net_namespace.h:15,
from net/ipv4/proc.c:35:
include/net/netns/packet.h:11: error: field 'sklist_lock' has incomplete type
...
The lock of netns_packet has been replaced by a recent patch to be a mutex instead of a spinlock,
but we need to replace the header file to be linux/mutex.h instead of linux/spinlock.h as well.
See commit 0fa7fa98dbcc2789409ed24e885485e645803d7f:
packet: Protect packet sk list with mutex (v2) patch,
Signed-off-by: Rami Rosen <rosenr@marvell.com>
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 348 bytes --]
diff --git a/include/net/netns/packet.h b/include/net/netns/packet.h
index 4780b08..17ec2b9 100644
--- a/include/net/netns/packet.h
+++ b/include/net/netns/packet.h
@@ -5,7 +5,7 @@
#define __NETNS_PACKET_H__
#include <linux/rculist.h>
-#include <linux/spinlock.h>
+#include <linux/mutex.h>
struct netns_packet {
struct mutex sklist_lock;
^ permalink raw reply related
* RE: [PATCH 1/1] tcp: Wrong timeout for SYN segments
From: Eric Dumazet @ 2012-08-23 12:51 UTC (permalink / raw)
To: David Laight; +Cc: Alex Bergmann, H.K. Jerry Chu, davem, netdev, linux-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6FC3@saturn3.aculab.com>
On Thu, 2012-08-23 at 13:35 +0100, David Laight wrote:
> > I would suggest to increase TCP_SYN_RETRIES from 5 to 6.
> >
> > 180 secs is eternity, but 31 secs is too small.
>
> Wasn't the intention of the long delay to allow a system
> acting as a router to reboot?
> I suspect that is why it (and some other TCP timers)
> are in minutes.
One could argue that if an application really wants to connect to a
peer, it should probably handle failures and retries.
But for unaware (basic ?) applications, the 3 -> 1 change reduced by a 3
factor the timeout. So a transient network failure has now more
chance to impact them.
Not all applications run inside a browser or under human control...
^ permalink raw reply
* Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS
From: Jesper Dangaard Brouer @ 2012-08-23 12:50 UTC (permalink / raw)
To: Julian Anastasov
Cc: netdev, Patrick McHardy, Hans Schillstrom, lvs-devel,
Simon Horman, Wensong Zhang, netfilter-devel
In-Reply-To: <alpine.LFD.2.00.1208211558410.2149@ja.ssi.bg>
On Tue, 2012-08-21 at 17:14 +0300, Julian Anastasov wrote:
> On Mon, 20 Aug 2012, Jesper Dangaard Brouer wrote:
>
> > Based on patch from: Hans Schillstrom
> >
> > IPv6 headers must be processed in order of appearance,
> > neither can it be assumed that Upper layer headers is first.
> > If anything else than L4 is the first header IPVS will throw it.
> >
> > IPVS will write SNAT & DNAT modifications at a fixed pos which
> > will corrupt the message. Proper header position must be found
> > before writing modifying packet.
> >
> > This patch contains a lot of API changes. This is done, to avoid
> > the costly scan of finding the IPv6 headers, via ipv6_find_hdr().
> > Finding the IPv6 headers is done as early as possible, and passed
> > on as a pointer "struct ip_vs_iphdr *" to the affected functions.
> >
> > Notice, I have choosen, not to change the API of function
> > pointer "(*schedule)" (in struct ip_vs_scheduler) as it can be
> > used by external schedulers, via {un,}register_ip_vs_scheduler.
> > Only 4 out of 10 schedulers use info from ip_vs_iphdr*, and when
> > they do, they are only interested in iph->{s,d}addr.
> >
> > This patch depends on commit 84018f55a:
> > "netfilter: ip6_tables: add flags parameter to ipv6_find_hdr()"
> >
> > This also adds a dependency to ip6_tables.
> >
> > Hans left some questions in ip_vs_pe_sip.c, which I'm uncertain about.
> >
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
>
> Patch 1 looks ok, following are some small comments
> for patch 2 and 3.
>
> > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> > +#include <linux/netfilter_ipv6/ip6_tables.h>
> > +#endif
>
> There is already #if IS_ENABLED(CONFIG_IPV6) that
> can replace #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
Okay.
> It seems we need IS_ENABLED for many places:
> CONFIG_NF_CONNTRACK, CONFIG_NF_DEFRAG_IPV6
Wondering if we should keep these cleanup changes to a separate patch.
> > @@ -958,34 +943,26 @@ static int ip_vs_out_icmp_v6(struct sk_buff *skb, int *related,
> > }
> >
> > /* Now find the contained IP header */
> > - offset += sizeof(_icmph);
> > - cih = skb_header_pointer(skb, offset, sizeof(_ciph), &_ciph);
> > - if (cih == NULL)
> > - return NF_ACCEPT; /* The packet looks wrong, ignore */
> > + ipvsh->len += sizeof(_icmph);
> > + ip6 = skb_header_pointer(skb, ipvsh->len, sizeof(_ip6), &_ip6);
>
> ip6 is not checked here for NULL or we rely on
> ipv6_find_hdr checks?
Good catch, I'll re-add the NULL pointer check.
> > @@ -1506,39 +1464,43 @@ ip_vs_in_icmp_v6(struct sk_buff *skb, int *related, unsigned int hooknum)
> > }
> >
> > /* Now find the contained IP header */
> > - offset += sizeof(_icmph);
> > - cih = skb_header_pointer(skb, offset, sizeof(_ciph), &_ciph);
> > - if (cih == NULL)
> > - return NF_ACCEPT; /* The packet looks wrong, ignore */
> > + ciph.len = iph->len + sizeof(_icmph);
> > + ciph.flags = 0;
> > + ciph.fragoffs = 0;
> > + ciph.protocol = ipv6_find_hdr(skb, &ciph.len, -1, &ciph.fragoffs,
> > + &ciph.flags);
(notice that &ciph.len can get updated by ipv6_find_hdr())
> > + ciph.saddr = iph->saddr; /* con_in_get() handles reverse order */
> > + ciph.daddr = iph->daddr;
>
> The ciph initialization looks dangerous if one day
> we add new field into the header.
>
> Can we use ciph = (struct ip_vs_iphdr) { .XXX = val, ... },
> in such case we have to call ipv6_find_hdr out of (after)
> this initialization? Of course, we will write twice to
> small fields such as protocol, len, fragoffs, flags
I'm not sure I follow/understand.
> Also ipv6_find_hdr looks a bit noisy for missing header,
> can it be a problem for the inner IPv6 header in ICMP messages?
I can see, that I don't handle the error cases of missing headers, from
a call to ipv6_find_hdr() ... I guess I need to check if the return
value "protocol" is negative. But I'm not sure if it matters in this
case (Hans?)
> In patch 3 ip_vs_in_icmp_v6 initializes ciph in the
> same way. It will be difficult to audit the code later
> considering the large number of places where iph is used.
I'm not sure what you want me to do?
> > net = skb_net(skb);
> > - pd = ip_vs_proto_data_get(net, cih->nexthdr);
> > + pd = ip_vs_proto_data_get(net, ciph.protocol);
> > if (!pd)
> > return NF_ACCEPT;
> > pp = pd->pp;
> >
> > - /* Is the embedded protocol header present? */
> > - /* TODO: we don't support fragmentation at the moment anyways */
> > - if (unlikely(cih->nexthdr == IPPROTO_FRAGMENT && pp->dont_defrag))
> > + /* Is the embedded protocol header present?
> > + * If it's the second or later fragment we don't know what it is
> > + * i.e. just let it through.
> > + */
> > + if (ciph.fragoffs)
> > return NF_ACCEPT;
> >
> > + offset = ciph.len;
> > IP_VS_DBG_PKT(11, AF_INET6, pp, skb, offset,
> > "Checking incoming ICMPv6 for");
> >
> > - offset += sizeof(struct ipv6hdr);
> > -
> > - ip_vs_fill_iphdr(AF_INET6, cih, &ciph);
> > /* The embedded headers contain source and dest in reverse order */
> > - cp = pp->conn_in_get(AF_INET6, skb, &ciph, offset, 1);
> > + cp = pp->conn_in_get(AF_INET6, skb, &ciph, 1);
> > if (!cp)
> > return NF_ACCEPT;
> >
> > /* do the statistics and put it back */
> > ip_vs_in_stats(cp, skb);
> > - if (IPPROTO_TCP == cih->nexthdr || IPPROTO_UDP == cih->nexthdr ||
> > - IPPROTO_SCTP == cih->nexthdr)
> > - offset += 2 * sizeof(__u16);
> > - verdict = ip_vs_icmp_xmit_v6(skb, cp, pp, offset, hooknum);
> > + if (IPPROTO_TCP == ciph.protocol || IPPROTO_UDP == ciph.protocol ||
> > + IPPROTO_SCTP == ciph.protocol)
> > + offset = ciph.len + (2 * sizeof(__u16));
>
> Still in the same func, above code is correct but
> patch 3 changes it back to wrong state (offs_ciph = ciph.len).
Don't think its a "bug" in patch3, it might be a "bug" in this patch.
Because &ciph.len gets updated earlier by ipv6_find_hdr()... but I'm
starting to get confused.
Perhaps we should move these changes to ip_vs_in_icmp_v6() into the same
patch?
> > +
> > + verdict = ip_vs_icmp_xmit_v6(skb, cp, pp, offset, hooknum, &ciph);
> >
> > __ip_vs_conn_put(cp);
>
> > diff --git a/net/netfilter/ipvs/ip_vs_pe_sip.c b/net/netfilter/ipvs/ip_vs_pe_sip.c
> > index 1aa5cac..bb28b4f 100644
> > --- a/net/netfilter/ipvs/ip_vs_pe_sip.c
> > +++ b/net/netfilter/ipvs/ip_vs_pe_sip.c
> > @@ -68,26 +68,37 @@ static int get_callid(const char *dptr, unsigned int dataoff,
> > static int
> > ip_vs_sip_fill_param(struct ip_vs_conn_param *p, struct sk_buff *skb)
> > {
> > + struct sk_buff *reasm = skb_nfct_reasm(skb);
> > struct ip_vs_iphdr iph;
> > unsigned int dataoff, datalen, matchoff, matchlen;
> > const char *dptr;
> > int retc;
> >
> > - ip_vs_fill_iphdr(p->af, skb_network_header(skb), &iph);
> > + ip_vs_fill_iph_skb(p->af, skb, &iph);
>
> May be skb_linearize is bad for IPv6? IIRC,
> ip_vs_pe_sip.c needs access just to read the Call-ID.
> For IPv4 it was simple to use skb_linearize, may be
> the logic should be improved to read the values even
> from non-linear data. May be there is already some
> example code for this. For IPv6 I'm not sure what
> kind are the problems here, may be it depends if
> we try to call skb_linearize for reasm packet?
I'm not able to answer these questions, my self...
> > -
> > - if ((retc=skb_linearize(skb)) < 0)
> > + /*
> > + * todo: Check if this will mess-up the reasm skb !!! /HS
> > + */
> > + retc = skb_linearize(reasm);
> > + if (retc < 0)
> > return retc;
> > - dptr = skb->data + dataoff;
> > - datalen = skb->len - dataoff;
> > + dptr = reasm->data + dataoff;
> > + datalen = reasm->len - dataoff;
> >
> > if (get_callid(dptr, dataoff, datalen, &matchoff, &matchlen))
> > return -EINVAL;
>
> There are recents changes for IPv6 from Patrick McHardy:
>
> http://marc.info/?l=netfilter-devel&m=134543406303402&w=2
> http://marc.info/?l=netfilter-devel&m=134543407803412&w=2
>
> In this context, may be soon we will modify ip_vs_ftp to
> support IPv6. It is possible to work with present FTP helper
> in netfilter. Does it mean that we will see only reassembled
> packets when conntrack is running? No original fragments.
Yes, it seems that we will *only* see the reassembled packet (no
original fragments) after Patricks patches. BUT *only* when loading the
module nf_conntrack_ipv6.
> Are we prepared to work in both ways (originals+reasm and
> just reasm) ?
As mentioned in another thread, no. But only because the reassembled
packet will be dropped due to the MTU check. After this is fixed, the
ipvs code seems to work. (Notice, this is both without and with my/these
patches)
> - For patch 3 in Kconfig do we need 'select NF_DEFRAG_IPV6' ?
Yes, but it is still possible not to load the module nf_defrag_ipv6.
When not loading, nf_defrag_ipv6, these patches have no effect, and no
fragments are passed through.
> Basicly, I'm concerned what will happen when we
> start to mangle the protocol payloads (FTP). For now
> we are safe by touching only addresses and ports. May be
> we have to synchronize these changes with the work from
> Patrick.
Yes, I think we should take Patrick's work into account.
My biggest concern is, that depending on which modules (nf_defrag_ipv6
only, or also nf_conntrack_ipv6) are loaded, different code paths are
used (to support IPv6 fragments for IPVS).
This will be hard to understand, from a user perspective. And also
difficult for us, when users report bugs...
Is loading nf_conntrack_ipv6 considered a big performance problem/issue
for IPVS?
(Can we tell people, to enable conntrack for frag support?)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 1/1] tcp: Wrong timeout for SYN segments
From: Eric Dumazet @ 2012-08-23 12:49 UTC (permalink / raw)
To: Alex Bergmann; +Cc: H.K. Jerry Chu, davem, netdev, linux-kernel
In-Reply-To: <50362407.9070805@linlab.net>
On Thu, 2012-08-23 at 14:37 +0200, Alex Bergmann wrote:
>
> From be551f82499112e4775b6d579d58967510b6d492 Mon Sep 17 00:00:00 2001
> From: Alexander Bergmann <alex@linlab.net>
> Date: Thu, 23 Aug 2012 14:33:35 +0200
> Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments
>
> Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
> RFC6298 (former RFC2988bis). This reduced the time till the last SYN
> retransmission packet gets sent from 93secs to 31secs.
>
> RFC1122 is stating that the retransmission should be done for at least 3
> minutes, but this seems to be quite high.[1]
>
> This patch increases the value of TCP_SYN_RETRIES to the value of 6,
> providing a retransmission window of 63secs.
>
> [1] RFC 1122 - 4.2.3.5 TCP Connection Failures
>
> Signed-off-by: Alexander Bergmann <alex@linlab.net>
> ---
> include/net/tcp.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 1f000ff..f309e93 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -98,7 +98,7 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
> * 15 is ~13-30min depending on RTO.
> */
>
> -#define TCP_SYN_RETRIES 5 /* number of times to retry active opening a
> +#define TCP_SYN_RETRIES 6 /* number of times to retry active opening a
> * connection: ~180sec is RFC minimum */
>
> #define TCP_SYNACK_RETRIES 5 /* number of times to retry passive opening a
Acked-by: Eric Dumazet <edumazet@google.com>
A change of the comment might be good, to help future readers.
^ permalink raw reply
* [PATCH net-next V3 1/2] IB/ipoib: Add rtnl_link_ops support
From: Or Gerlitz @ 2012-08-23 12:15 UTC (permalink / raw)
To: davem; +Cc: roland, netdev, Or Gerlitz, Erez Shitrit
In-Reply-To: <1345724119-32110-1-git-send-email-ogerlitz@mellanox.com>
Add rtnl_link_ops to IPoIB, with the first usage being child device
create/delete through them. Childs devices are now either legacy ones,
created/deleted through the ipoib sysfs entries, or RTNL ones.
Adding support for RTNL childs involved refactoring of ipoib_vlan_add
which is now used by both the sysfs and the link_ops code.
Also, added ndo_uninit entry to support calling unregister_netdevice_queue
from the rtnl dellink entry. This required removal of calls to
ipoib_dev_cleanup from the driver in flows which use unregister_netdevice,
since the networking core will invoke ipoib_uninit which does exactly that.
Signed-off-by: Erez Shitrit <erezsh@mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
Documentation/infiniband/ipoib.txt | 3 +
drivers/infiniband/ulp/ipoib/Makefile | 3 +-
drivers/infiniband/ulp/ipoib/ipoib.h | 13 +++
drivers/infiniband/ulp/ipoib/ipoib_main.c | 25 ++++-
drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 122 ++++++++++++++++++++++++++
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 102 ++++++++++++----------
6 files changed, 217 insertions(+), 51 deletions(-)
create mode 100644 drivers/infiniband/ulp/ipoib/ipoib_netlink.c
diff --git a/Documentation/infiniband/ipoib.txt b/Documentation/infiniband/ipoib.txt
index 64eeb55..f2cfe26 100644
--- a/Documentation/infiniband/ipoib.txt
+++ b/Documentation/infiniband/ipoib.txt
@@ -24,6 +24,9 @@ Partitions and P_Keys
The P_Key for any interface is given by the "pkey" file, and the
main interface for a subinterface is in "parent."
+ Child interface create/delete can also be done using IPoIB's
+ rtnl_link_ops, where childs created using either way behave the same.
+
Datagram vs Connected modes
The IPoIB driver supports two modes of operation: datagram and
diff --git a/drivers/infiniband/ulp/ipoib/Makefile b/drivers/infiniband/ulp/ipoib/Makefile
index 3090100..e5430dd 100644
--- a/drivers/infiniband/ulp/ipoib/Makefile
+++ b/drivers/infiniband/ulp/ipoib/Makefile
@@ -5,7 +5,8 @@ ib_ipoib-y := ipoib_main.o \
ipoib_multicast.o \
ipoib_verbs.o \
ipoib_vlan.o \
- ipoib_ethtool.o
+ ipoib_ethtool.o \
+ ipoib_netlink.o
ib_ipoib-$(CONFIG_INFINIBAND_IPOIB_CM) += ipoib_cm.o
ib_ipoib-$(CONFIG_INFINIBAND_IPOIB_DEBUG) += ipoib_fs.o
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h b/drivers/infiniband/ulp/ipoib/ipoib.h
index ca43901..381f51b 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -104,6 +104,10 @@ enum {
MAX_SEND_CQE = 16,
IPOIB_CM_COPYBREAK = 256,
+
+ IPOIB_NON_CHILD = 0,
+ IPOIB_LEGACY_CHILD = 1,
+ IPOIB_RTNL_CHILD = 2,
};
#define IPOIB_OP_RECV (1ul << 31)
@@ -350,6 +354,7 @@ struct ipoib_dev_priv {
struct net_device *parent;
struct list_head child_intfs;
struct list_head list;
+ int child_type;
#ifdef CONFIG_INFINIBAND_IPOIB_CM
struct ipoib_cm_dev_priv cm;
@@ -509,6 +514,14 @@ void ipoib_event(struct ib_event_handler *handler,
int ipoib_vlan_add(struct net_device *pdev, unsigned short pkey);
int ipoib_vlan_delete(struct net_device *pdev, unsigned short pkey);
+int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
+ u16 pkey, int child_type);
+
+int __init ipoib_netlink_init(void);
+void __exit ipoib_netlink_fini(void);
+
+void ipoib_setup(struct net_device *dev);
+
void ipoib_pkey_poll(struct work_struct *work);
int ipoib_pkey_dev_delay_open(struct net_device *dev);
void ipoib_drain_cq(struct net_device *dev);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 3e2085a..b3e9709 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -173,6 +173,11 @@ static int ipoib_stop(struct net_device *dev)
return 0;
}
+static void ipoib_uninit(struct net_device *dev)
+{
+ ipoib_dev_cleanup(dev);
+}
+
static netdev_features_t ipoib_fix_features(struct net_device *dev, netdev_features_t features)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
@@ -1262,6 +1267,9 @@ out:
void ipoib_dev_cleanup(struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev), *cpriv, *tcpriv;
+ LIST_HEAD(head);
+
+ ASSERT_RTNL();
ipoib_delete_debug_files(dev);
@@ -1270,10 +1278,9 @@ void ipoib_dev_cleanup(struct net_device *dev)
/* Stop GC on child */
set_bit(IPOIB_STOP_NEIGH_GC, &cpriv->flags);
cancel_delayed_work(&cpriv->neigh_reap_task);
- unregister_netdev(cpriv->dev);
- ipoib_dev_cleanup(cpriv->dev);
- free_netdev(cpriv->dev);
+ unregister_netdevice_queue(cpriv->dev, &head);
}
+ unregister_netdevice_many(&head);
ipoib_ib_dev_cleanup(dev);
@@ -1291,6 +1298,7 @@ static const struct header_ops ipoib_header_ops = {
};
static const struct net_device_ops ipoib_netdev_ops = {
+ .ndo_uninit = ipoib_uninit,
.ndo_open = ipoib_open,
.ndo_stop = ipoib_stop,
.ndo_change_mtu = ipoib_change_mtu,
@@ -1300,7 +1308,7 @@ static const struct net_device_ops ipoib_netdev_ops = {
.ndo_set_rx_mode = ipoib_set_mcast_list,
};
-static void ipoib_setup(struct net_device *dev)
+void ipoib_setup(struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
@@ -1662,7 +1670,6 @@ static void ipoib_remove_one(struct ib_device *device)
flush_workqueue(ipoib_workqueue);
unregister_netdev(priv->dev);
- ipoib_dev_cleanup(priv->dev);
free_netdev(priv->dev);
}
@@ -1714,8 +1721,15 @@ static int __init ipoib_init_module(void)
if (ret)
goto err_sa;
+ ret = ipoib_netlink_init();
+ if (ret)
+ goto err_client;
+
return 0;
+err_client:
+ ib_unregister_client(&ipoib_client);
+
err_sa:
ib_sa_unregister_client(&ipoib_sa_client);
destroy_workqueue(ipoib_workqueue);
@@ -1728,6 +1742,7 @@ err_fs:
static void __exit ipoib_cleanup_module(void)
{
+ ipoib_netlink_fini();
ib_unregister_client(&ipoib_client);
ib_sa_unregister_client(&ipoib_sa_client);
ipoib_unregister_debugfs();
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
new file mode 100644
index 0000000..18d6ac9
--- /dev/null
+++ b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright (c) 2012 Mellanox Technologies. - All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials
+ * provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include <linux/netdevice.h>
+#include <linux/module.h>
+#include <net/rtnetlink.h>
+#include "ipoib.h"
+
+enum {
+ IFLA_IPOIB_UNSPEC,
+ IFLA_IPOIB_CHILD_PKEY,
+ __IFLA_IPOIB_MAX
+};
+
+#define IFLA_IPOIB_MAX (__IFLA_IPOIB_MAX - 1)
+
+static const struct nla_policy ipoib_policy[IFLA_IPOIB_MAX + 1] = {
+ [IFLA_IPOIB_CHILD_PKEY] = { .type = NLA_U16 },
+};
+
+static int ipoib_new_child_link(struct net *src_net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ struct net_device *pdev;
+ struct ipoib_dev_priv *ppriv;
+ u16 child_pkey;
+ int err;
+
+ if (!tb[IFLA_LINK])
+ return -EINVAL;
+
+ pdev = __dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
+ if (!pdev)
+ return -ENODEV;
+
+ ppriv = netdev_priv(pdev);
+
+ if (test_bit(IPOIB_FLAG_SUBINTERFACE, &ppriv->flags)) {
+ ipoib_warn(ppriv, "child creation disallowed for child devices\n");
+ return -EINVAL;
+ }
+
+ if (!data || !data[IFLA_IPOIB_CHILD_PKEY]) {
+ ipoib_dbg(ppriv, "no pkey specified, using parent pkey\n");
+ child_pkey = ppriv->pkey;
+ } else
+ child_pkey = nla_get_u16(data[IFLA_IPOIB_CHILD_PKEY]);
+
+ err = __ipoib_vlan_add(ppriv, netdev_priv(dev), child_pkey, IPOIB_RTNL_CHILD);
+
+ return err;
+}
+
+static void ipoib_unregister_child_dev(struct net_device *dev, struct list_head *head)
+{
+ struct ipoib_dev_priv *priv, *ppriv;
+
+ priv = netdev_priv(dev);
+ ppriv = netdev_priv(priv->parent);
+
+ mutex_lock(&ppriv->vlan_mutex);
+ unregister_netdevice_queue(dev, head);
+ list_del(&priv->list);
+ mutex_unlock(&ppriv->vlan_mutex);
+}
+
+static size_t ipoib_get_size(const struct net_device *dev)
+{
+ return nla_total_size(2); /* IFLA_IPOIB_CHILD_PKEY */
+}
+
+static struct rtnl_link_ops ipoib_link_ops __read_mostly = {
+ .kind = "ipoib",
+ .maxtype = IFLA_IPOIB_MAX,
+ .policy = ipoib_policy,
+ .priv_size = sizeof(struct ipoib_dev_priv),
+ .setup = ipoib_setup,
+ .newlink = ipoib_new_child_link,
+ .dellink = ipoib_unregister_child_dev,
+ .get_size = ipoib_get_size,
+};
+
+int __init ipoib_netlink_init(void)
+{
+ return rtnl_link_register(&ipoib_link_ops);
+}
+
+void __exit ipoib_netlink_fini(void)
+{
+ rtnl_link_unregister(&ipoib_link_ops);
+}
+
+MODULE_ALIAS_RTNL_LINK("ipoib");
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
index d7e9740..238bbf9 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -49,47 +49,11 @@ static ssize_t show_parent(struct device *d, struct device_attribute *attr,
}
static DEVICE_ATTR(parent, S_IRUGO, show_parent, NULL);
-int ipoib_vlan_add(struct net_device *pdev, unsigned short pkey)
+int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
+ u16 pkey, int type)
{
- struct ipoib_dev_priv *ppriv, *priv;
- char intf_name[IFNAMSIZ];
int result;
- if (!capable(CAP_NET_ADMIN))
- return -EPERM;
-
- ppriv = netdev_priv(pdev);
-
- if (!rtnl_trylock())
- return restart_syscall();
- mutex_lock(&ppriv->vlan_mutex);
-
- /*
- * First ensure this isn't a duplicate. We check the parent device and
- * then all of the child interfaces to make sure the Pkey doesn't match.
- */
- if (ppriv->pkey == pkey) {
- result = -ENOTUNIQ;
- priv = NULL;
- goto err;
- }
-
- list_for_each_entry(priv, &ppriv->child_intfs, list) {
- if (priv->pkey == pkey) {
- result = -ENOTUNIQ;
- priv = NULL;
- goto err;
- }
- }
-
- snprintf(intf_name, sizeof intf_name, "%s.%04x",
- ppriv->dev->name, pkey);
- priv = ipoib_intf_alloc(intf_name);
- if (!priv) {
- result = -ENOMEM;
- goto err;
- }
-
priv->max_ib_mtu = ppriv->max_ib_mtu;
/* MTU will be reset when mcast join happens */
priv->dev->mtu = IPOIB_UD_MTU(priv->max_ib_mtu);
@@ -134,14 +98,13 @@ int ipoib_vlan_add(struct net_device *pdev, unsigned short pkey)
if (device_create_file(&priv->dev->dev, &dev_attr_parent))
goto sysfs_failed;
+ priv->child_type = type;
list_add_tail(&priv->list, &ppriv->child_intfs);
- mutex_unlock(&ppriv->vlan_mutex);
- rtnl_unlock();
-
return 0;
sysfs_failed:
+ result = -ENOMEM;
ipoib_delete_debug_files(priv->dev);
unregister_netdevice(priv->dev);
@@ -149,11 +112,60 @@ register_failed:
ipoib_dev_cleanup(priv->dev);
err:
+ return result;
+}
+
+int ipoib_vlan_add(struct net_device *pdev, unsigned short pkey)
+{
+ struct ipoib_dev_priv *ppriv, *priv;
+ char intf_name[IFNAMSIZ];
+ struct ipoib_dev_priv *tpriv;
+ int result;
+
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
+ ppriv = netdev_priv(pdev);
+
+ snprintf(intf_name, sizeof intf_name, "%s.%04x",
+ ppriv->dev->name, pkey);
+ priv = ipoib_intf_alloc(intf_name);
+ if (!priv)
+ return -ENOMEM;
+
+ if (!rtnl_trylock())
+ return restart_syscall();
+
+ mutex_lock(&ppriv->vlan_mutex);
+
+ /*
+ * First ensure this isn't a duplicate. We check the parent device and
+ * then all of the legacy child interfaces to make sure the Pkey
+ * doesn't match.
+ */
+ if (ppriv->pkey == pkey) {
+ result = -ENOTUNIQ;
+ goto out;
+ }
+
+ list_for_each_entry(tpriv, &ppriv->child_intfs, list) {
+ if (tpriv->pkey == pkey &&
+ tpriv->child_type == IPOIB_LEGACY_CHILD) {
+ result = -ENOTUNIQ;
+ goto out;
+ }
+ }
+
+ result = __ipoib_vlan_add(ppriv, priv, pkey, IPOIB_LEGACY_CHILD);
+
+out:
mutex_unlock(&ppriv->vlan_mutex);
- rtnl_unlock();
- if (priv)
+
+ if (result)
free_netdev(priv->dev);
+ rtnl_unlock();
+
return result;
}
@@ -171,9 +183,9 @@ int ipoib_vlan_delete(struct net_device *pdev, unsigned short pkey)
return restart_syscall();
mutex_lock(&ppriv->vlan_mutex);
list_for_each_entry_safe(priv, tpriv, &ppriv->child_intfs, list) {
- if (priv->pkey == pkey) {
+ if (priv->pkey == pkey &&
+ priv->child_type == IPOIB_LEGACY_CHILD) {
unregister_netdevice(priv->dev);
- ipoib_dev_cleanup(priv->dev);
list_del(&priv->list);
dev = priv->dev;
break;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/1] tcp: Wrong timeout for SYN segments
From: Alex Bergmann @ 2012-08-23 12:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: H.K. Jerry Chu, davem, netdev, linux-kernel
In-Reply-To: <1345724123.5904.756.camel@edumazet-glaptop>
On 08/23/2012 02:15 PM, Eric Dumazet wrote:
> On Thu, 2012-08-23 at 13:58 +0200, Alex Bergmann wrote:
>> On 08/22/2012 06:41 PM, H.K. Jerry Chu wrote:
>
>>> This issue occurred to me right after I submitted the patch for RFC6298.
>>> I did not commit any more change because RFC compliance aside, 180secs
>>> just seem like eternity in the Internet age.
>>>
>>> (See my past post on this at
>>> http://marc.info/?l=linux-netdev&m=130759078118866&w=2)
>>
>> Okay, I missed that post during my search about the current situation.
>
> I would suggest to increase TCP_SYN_RETRIES from 5 to 6.
>
> 180 secs is eternity, but 31 secs is too small.
>
> Can you repost a v2, only changing TCP_SYN_RETRIES ?
I hope the description is good enough.
Alex
>From be551f82499112e4775b6d579d58967510b6d492 Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <alex@linlab.net>
Date: Thu, 23 Aug 2012 14:33:35 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments
Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
RFC6298 (former RFC2988bis). This reduced the time till the last SYN
retransmission packet gets sent from 93secs to 31secs.
RFC1122 is stating that the retransmission should be done for at least 3
minutes, but this seems to be quite high.[1]
This patch increases the value of TCP_SYN_RETRIES to the value of 6,
providing a retransmission window of 63secs.
[1] RFC 1122 - 4.2.3.5 TCP Connection Failures
Signed-off-by: Alexander Bergmann <alex@linlab.net>
---
include/net/tcp.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 1f000ff..f309e93 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -98,7 +98,7 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
* 15 is ~13-30min depending on RTO.
*/
-#define TCP_SYN_RETRIES 5 /* number of times to retry active opening a
+#define TCP_SYN_RETRIES 6 /* number of times to retry active opening a
* connection: ~180sec is RFC minimum */
#define TCP_SYNACK_RETRIES 5 /* number of times to retry passive opening a
--
1.7.8.6
^ permalink raw reply related
* RE: [PATCH 1/1] tcp: Wrong timeout for SYN segments
From: David Laight @ 2012-08-23 12:35 UTC (permalink / raw)
To: Eric Dumazet, Alex Bergmann; +Cc: H.K. Jerry Chu, davem, netdev, linux-kernel
In-Reply-To: <1345724123.5904.756.camel@edumazet-glaptop>
> I would suggest to increase TCP_SYN_RETRIES from 5 to 6.
>
> 180 secs is eternity, but 31 secs is too small.
Wasn't the intention of the long delay to allow a system
acting as a router to reboot?
I suspect that is why it (and some other TCP timers)
are in minutes.
David
^ permalink raw reply
* Re: [PATCH v8] bonding: support for IPv6 transmit hashing
From: Jeremy Brookman @ 2012-08-23 12:23 UTC (permalink / raw)
To: John Eaglesham; +Cc: netdev
In-Reply-To: <2e01d8f94c42c61af9886683a4c35caf6816bc3d.1345615999.git.linux@8192.net>
Thanks for getting this in John. Apologies for my earlier reply,
where I hadn't spotted this revision of the patch; it looks like the
comments I made have been addressed, and all is well.
Thanks again,
Jeremy
On Wed, Aug 22, 2012 at 7:43 AM, John Eaglesham <linux@8192.net> wrote:
> From: John Eaglesham <linux@8192.net>
>
> Currently the "bonding" driver does not support load balancing outgoing
> traffic in LACP mode for IPv6 traffic. IPv4 (and TCP or UDP over IPv4)
> are currently supported; this patch adds transmit hashing for IPv6 (and
> TCP or UDP over IPv6), bringing IPv6 up to par with IPv4 support in the
> bonding driver. In addition, bounds checking has been added to all
> transmit hashing functions.
>
> The algorithm chosen (xor'ing the bottom three quads of the source and
> destination addresses together, then xor'ing each byte of that result into
> the bottom byte, finally xor'ing with the last bytes of the MAC addresses)
> was selected after testing almost 400,000 unique IPv6 addresses harvested
> from server logs. This algorithm had the most even distribution for both
> big- and little-endian architectures while still using few instructions. Its
> behavior also attempts to closely match that of the IPv4 algorithm.
>
> The IPv6 flow label was intentionally not included in the hash as it appears
> to be unset in the vast majority of IPv6 traffic sampled, and the current
> algorithm not using the flow label already offers a very even distribution.
>
> Fragmented IPv6 packets are handled the same way as fragmented IPv4 packets,
> ie, they are not balanced based on layer 4 information. Additionally,
> IPv6 packets with intermediate headers are not balanced based on layer
> 4 information. In practice these intermediate headers are not common and
> this should not cause any problems, and the alternative (a packet-parsing
> loop and look-up table) seemed slow and complicated for little gain.
>
> Tested-by: John Eaglesham <linux@8192.net>
> Signed-off-by: John Eaglesham <linux@8192.net>
>
> ---
>
> Changes:
> v2)
> * Clarify description
> * Add bounds checking to more functions
> * All functions call bond_xmit_hash_policy_l2 rather than re-
> implement the same logic.
> v3)
> * Patch against net-next.
> * Style corrections.
> v4)
> * Correct indenting.
> v5)
> * Squash documentation and code patches into one.
> v6)
> * Modify IPv6 hash to behave more like the IPv4 hash, update
> documentation with modified algorithm.
> * Clean up formatting.
> * Move all variable declaration to the top of the function.
> * Minor change to IPv6 layer 4 hash to match IPv4 hash behavior
> (mix all hashed address bits together rather than just the
> bottom 24 bits).
> v7)
> * Improve bounds checking code (handle truncated IPv6 header,
> removed goto, fewer if statements).
> * Re-write pseudocode in documentation to match actual code more
> closely.
> * Correct indenting, align parentheses, wrap code at <= 80 columns
> (based on Jay's changes).
> v8)
> * Correct patch submission format.
>
> Documentation/networking/bonding.txt | 30 ++++++++++--
> drivers/net/bonding/bond_main.c | 89 +++++++++++++++++++++++++-----------
> 2 files changed, 88 insertions(+), 31 deletions(-)
>
> diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
> index 6b1c711..10a015c 100644
> --- a/Documentation/networking/bonding.txt
> +++ b/Documentation/networking/bonding.txt
> @@ -752,12 +752,22 @@ xmit_hash_policy
> protocol information to generate the hash.
>
> Uses XOR of hardware MAC addresses and IP addresses to
> - generate the hash. The formula is
> + generate the hash. The IPv4 formula is
>
> (((source IP XOR dest IP) AND 0xffff) XOR
> ( source MAC XOR destination MAC ))
> modulo slave count
>
> + The IPv6 formula is
> +
> + hash = (source ip quad 2 XOR dest IP quad 2) XOR
> + (source ip quad 3 XOR dest IP quad 3) XOR
> + (source ip quad 4 XOR dest IP quad 4)
> +
> + (((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash)
> + XOR (source MAC XOR destination MAC))
> + modulo slave count
> +
> This algorithm will place all traffic to a particular
> network peer on the same slave. For non-IP traffic,
> the formula is the same as for the layer2 transmit
> @@ -778,19 +788,29 @@ xmit_hash_policy
> slaves, although a single connection will not span
> multiple slaves.
>
> - The formula for unfragmented TCP and UDP packets is
> + The formula for unfragmented IPv4 TCP and UDP packets is
>
> ((source port XOR dest port) XOR
> ((source IP XOR dest IP) AND 0xffff)
> modulo slave count
>
> - For fragmented TCP or UDP packets and all other IP
> - protocol traffic, the source and destination port
> + The formula for unfragmented IPv6 TCP and UDP packets is
> +
> + hash = (source port XOR dest port) XOR
> + ((source ip quad 2 XOR dest IP quad 2) XOR
> + (source ip quad 3 XOR dest IP quad 3) XOR
> + (source ip quad 4 XOR dest IP quad 4))
> +
> + ((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash)
> + modulo slave count
> +
> + For fragmented TCP or UDP packets and all other IPv4 and
> + IPv6 protocol traffic, the source and destination port
> information is omitted. For non-IP traffic, the
> formula is the same as for the layer2 transmit hash
> policy.
>
> - This policy is intended to mimic the behavior of
> + The IPv4 policy is intended to mimic the behavior of
> certain switches, notably Cisco switches with PFC2 as
> well as some Foundry and IBM products.
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index d95fbc3..4221e57 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -3354,56 +3354,93 @@ static struct notifier_block bond_netdev_notifier = {
> /*---------------------------- Hashing Policies -----------------------------*/
>
> /*
> + * Hash for the output device based upon layer 2 data
> + */
> +static int bond_xmit_hash_policy_l2(struct sk_buff *skb, int count)
> +{
> + struct ethhdr *data = (struct ethhdr *)skb->data;
> +
> + if (skb_headlen(skb) >= offsetof(struct ethhdr, h_proto))
> + return (data->h_dest[5] ^ data->h_source[5]) % count;
> +
> + return 0;
> +}
> +
> +/*
> * Hash for the output device based upon layer 2 and layer 3 data. If
> - * the packet is not IP mimic bond_xmit_hash_policy_l2()
> + * the packet is not IP, fall back on bond_xmit_hash_policy_l2()
> */
> static int bond_xmit_hash_policy_l23(struct sk_buff *skb, int count)
> {
> struct ethhdr *data = (struct ethhdr *)skb->data;
> - struct iphdr *iph = ip_hdr(skb);
> -
> - if (skb->protocol == htons(ETH_P_IP)) {
> + struct iphdr *iph;
> + struct ipv6hdr *ipv6h;
> + u32 v6hash;
> + __be32 *s, *d;
> +
> + if (skb->protocol == htons(ETH_P_IP) &&
> + skb_network_header_len(skb) >= sizeof(*iph)) {
> + iph = ip_hdr(skb);
> return ((ntohl(iph->saddr ^ iph->daddr) & 0xffff) ^
> (data->h_dest[5] ^ data->h_source[5])) % count;
> + } else if (skb->protocol == htons(ETH_P_IPV6) &&
> + skb_network_header_len(skb) >= sizeof(*ipv6h)) {
> + ipv6h = ipv6_hdr(skb);
> + s = &ipv6h->saddr.s6_addr32[0];
> + d = &ipv6h->daddr.s6_addr32[0];
> + v6hash = (s[1] ^ d[1]) ^ (s[2] ^ d[2]) ^ (s[3] ^ d[3]);
> + v6hash ^= (v6hash >> 24) ^ (v6hash >> 16) ^ (v6hash >> 8);
> + return (v6hash ^ data->h_dest[5] ^ data->h_source[5]) % count;
> }
>
> - return (data->h_dest[5] ^ data->h_source[5]) % count;
> + return bond_xmit_hash_policy_l2(skb, count);
> }
>
> /*
> * Hash for the output device based upon layer 3 and layer 4 data. If
> * the packet is a frag or not TCP or UDP, just use layer 3 data. If it is
> - * altogether not IP, mimic bond_xmit_hash_policy_l2()
> + * altogether not IP, fall back on bond_xmit_hash_policy_l2()
> */
> static int bond_xmit_hash_policy_l34(struct sk_buff *skb, int count)
> {
> - struct ethhdr *data = (struct ethhdr *)skb->data;
> - struct iphdr *iph = ip_hdr(skb);
> - __be16 *layer4hdr = (__be16 *)((u32 *)iph + iph->ihl);
> - int layer4_xor = 0;
> -
> - if (skb->protocol == htons(ETH_P_IP)) {
> + u32 layer4_xor = 0;
> + struct iphdr *iph;
> + struct ipv6hdr *ipv6h;
> + __be32 *s, *d;
> + __be16 *layer4hdr;
> +
> + if (skb->protocol == htons(ETH_P_IP) &&
> + skb_network_header_len(skb) >= sizeof(*iph)) {
> + iph = ip_hdr(skb);
> if (!ip_is_fragment(iph) &&
> (iph->protocol == IPPROTO_TCP ||
> - iph->protocol == IPPROTO_UDP)) {
> - layer4_xor = ntohs((*layer4hdr ^ *(layer4hdr + 1)));
> + iph->protocol == IPPROTO_UDP) &&
> + (skb_headlen(skb) - skb_network_offset(skb) >=
> + iph->ihl * sizeof(u32) + sizeof(*layer4hdr) * 2)) {
> + layer4hdr = (__be16 *)((u32 *)iph + iph->ihl);
> + layer4_xor = ntohs(*layer4hdr ^ *(layer4hdr + 1));
> }
> return (layer4_xor ^
> ((ntohl(iph->saddr ^ iph->daddr)) & 0xffff)) % count;
> -
> + } else if (skb->protocol == htons(ETH_P_IPV6) &&
> + skb_network_header_len(skb) >= sizeof(*ipv6h)) {
> + ipv6h = ipv6_hdr(skb);
> + if ((ipv6h->nexthdr == IPPROTO_TCP ||
> + ipv6h->nexthdr == IPPROTO_UDP) &&
> + (skb_headlen(skb) - skb_network_offset(skb) >=
> + sizeof(*ipv6h) + sizeof(*layer4hdr) * 2)) {
> + layer4hdr = (__be16 *)(ipv6h + 1);
> + layer4_xor = ntohs(*layer4hdr ^ *(layer4hdr + 1));
> + }
> + s = &ipv6h->saddr.s6_addr32[0];
> + d = &ipv6h->daddr.s6_addr32[0];
> + layer4_xor ^= (s[1] ^ d[1]) ^ (s[2] ^ d[2]) ^ (s[3] ^ d[3]);
> + layer4_xor ^= (layer4_xor >> 24) ^ (layer4_xor >> 16) ^
> + (layer4_xor >> 8);
> + return layer4_xor % count;
> }
>
> - return (data->h_dest[5] ^ data->h_source[5]) % count;
> -}
> -
> -/*
> - * Hash for the output device based upon layer 2 data
> - */
> -static int bond_xmit_hash_policy_l2(struct sk_buff *skb, int count)
> -{
> - struct ethhdr *data = (struct ethhdr *)skb->data;
> -
> - return (data->h_dest[5] ^ data->h_source[5]) % count;
> + return bond_xmit_hash_policy_l2(skb, count);
> }
>
> /*-------------------------- Device entry points ----------------------------*/
> --
> 1.7.11
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH iproute2 2/2] iplink: added support for ipoib rtnl link ops
From: Or Gerlitz @ 2012-08-23 12:15 UTC (permalink / raw)
To: davem; +Cc: roland, netdev, Or Gerlitz
In-Reply-To: <1345724119-32110-1-git-send-email-ogerlitz@mellanox.com>
Added basic support to create/delete IPoIB child devices,
where the user can optionally specify the IB PKEY (Partition Key)
to be used by the newly created device. If nothing is provided,
the child will use the same pkey as the parent.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
include/linux/if_link.h | 9 ++++++
ip/Makefile | 2 +-
ip/iplink.c | 2 +-
ip/iplink_ipoib.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 84 insertions(+), 2 deletions(-)
create mode 100644 ip/iplink_ipoib.c
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 46f03db..7e64aa7 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -384,4 +384,13 @@ struct ifla_port_vsi {
__u8 pad[3];
};
+/* IPoIB section */
+enum {
+ IFLA_IPOIB_UNSPEC,
+ IFLA_IPOIB_CHILD_PKEY,
+ __IFLA_IPOIB_MAX
+};
+
+#define IFLA_IPOIB_MAX (__IFLA_IPOIB_MAX - 1)
+
#endif /* _LINUX_IF_LINK_H */
diff --git a/ip/Makefile b/ip/Makefile
index 6a518f8..ba2e2e6 100644
--- a/ip/Makefile
+++ b/ip/Makefile
@@ -3,7 +3,7 @@ IPOBJ=ip.o ipaddress.o ipaddrlabel.o iproute.o iprule.o ipnetns.o \
ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o iptuntap.o \
ipxfrm.o xfrm_state.o xfrm_policy.o xfrm_monitor.o \
iplink_vlan.o link_veth.o link_gre.o iplink_can.o \
- iplink_macvlan.o iplink_macvtap.o ipl2tp.o link_vti.o
+ iplink_macvlan.o iplink_macvtap.o ipl2tp.o link_vti.o iplink_ipoib.o
RTMONOBJ=rtmon.o
diff --git a/ip/iplink.c b/ip/iplink.c
index 4111871..7451aa0 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -83,7 +83,7 @@ void iplink_usage(void)
if (iplink_have_newlink()) {
fprintf(stderr, "\n");
- fprintf(stderr, "TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | can | bridge }\n");
+ fprintf(stderr, "TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | can | bridge | ipoib }\n");
}
exit(-1);
}
diff --git a/ip/iplink_ipoib.c b/ip/iplink_ipoib.c
new file mode 100644
index 0000000..7dea357
--- /dev/null
+++ b/ip/iplink_ipoib.c
@@ -0,0 +1,73 @@
+/*
+ * iplink_ipoib.c IPoIB device support
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Or Gerlitz <ogerlitz@mellanox.com>
+ * copied iflink_vlan.c authored by Patrick McHardy <kaber@trash.net>
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <linux/if_link.h>
+
+#include "rt_names.h"
+#include "utils.h"
+#include "ip_common.h"
+
+static void explain(void)
+{
+ fprintf(stderr,
+ "Usage: ... ipoib [pkey PKEY]\n"
+ "\n"
+ "PKEY := 0x8001-0xffff\n"
+ );
+}
+
+static int ipoib_parse_opt(struct link_util *lu, int argc, char **argv,
+ struct nlmsghdr *n)
+{
+ __u16 pkey;
+
+ while (argc > 0) {
+ if (matches(*argv, "pkey") == 0) {
+ NEXT_ARG();
+ if (get_u16(&pkey, *argv, 0))
+ invarg("pkey is invalid", *argv);
+ addattr_l(n, 1024, IFLA_IPOIB_CHILD_PKEY, &pkey, 2);
+ } else if (matches(*argv, "help") == 0) {
+ explain();
+ return -1;
+ } else {
+ fprintf(stderr, "ipoib: what is \"%s\"?\n", *argv);
+ explain();
+ return -1;
+ }
+ argc--, argv++;
+ }
+
+ return 0;
+}
+
+static void ipoib_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
+{
+ if (!tb)
+ return;
+
+ if (!tb[IFLA_IPOIB_CHILD_PKEY] ||
+ RTA_PAYLOAD(tb[IFLA_IPOIB_CHILD_PKEY]) < sizeof(__u16))
+ return;
+
+ fprintf(f, "pkey %.4x ", rta_getattr_u16(tb[IFLA_IPOIB_CHILD_PKEY]));
+}
+
+struct link_util ipoib_link_util = {
+ .id = "ipoib",
+ .maxattr = IFLA_IPOIB_MAX,
+ .parse_opt = ipoib_parse_opt,
+ .print_opt = ipoib_print_opt,
+};
--
1.7.1
^ permalink raw reply related
* [PATCH net-next V3 0/2] Add rtnl_link_ops support to IPoIB
From: Or Gerlitz @ 2012-08-23 12:15 UTC (permalink / raw)
To: davem; +Cc: roland, netdev, Or Gerlitz
This is about adding rtnl_link_ops to IPoIB, primarly addressing feedback
from Dave on a similar patch that was part of the eIPoIB submission.
Also added the releated iproute2 patch, for the sake of the review and
testing, e.g example usages:
$ ip link add link ib0 name ib0.1 type ipoib
$ ip link add link ib0 name ib0.8001 type ipoib pkey 0x8001
and the obvious
$ link delete dev ib0.8001
$ link delete dev ib0.1
Changes from V2:
- removed the notion of user defined index per child, since we can do well w.o it
- for that end, make (an internal to ipoib) distrinction between legacy childs created
through the old sysfs way to childs created using rtnl link ops
Changes from V1:
- applied feedback from Dave Miller to avoid using sysfs
- added rtnl_link_ops support in ipoib and use them to add/delete childs
Or Gerlitz (1):
IB/ipoib: Add rtnl_link_ops support
Documentation/infiniband/ipoib.txt | 3 +
drivers/infiniband/ulp/ipoib/Makefile | 3 +-
drivers/infiniband/ulp/ipoib/ipoib.h | 13 +++
drivers/infiniband/ulp/ipoib/ipoib_main.c | 25 ++++-
drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 122 ++++++++++++++++++++++++++
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 102 ++++++++++++----------
6 files changed, 217 insertions(+), 51 deletions(-)
create mode 100644 drivers/infiniband/ulp/ipoib/ipoib_netlink.c
^ permalink raw reply
* Re: [PATCH 1/1] tcp: Wrong timeout for SYN segments
From: Eric Dumazet @ 2012-08-23 12:15 UTC (permalink / raw)
To: Alex Bergmann; +Cc: H.K. Jerry Chu, davem, netdev, linux-kernel
In-Reply-To: <50361AEA.6010807@linlab.net>
On Thu, 2012-08-23 at 13:58 +0200, Alex Bergmann wrote:
> On 08/22/2012 06:41 PM, H.K. Jerry Chu wrote:
> > This issue occurred to me right after I submitted the patch for RFC6298.
> > I did not commit any more change because RFC compliance aside, 180secs
> > just seem like eternity in the Internet age.
> >
> > (See my past post on this at
> > http://marc.info/?l=linux-netdev&m=130759078118866&w=2)
>
> Okay, I missed that post during my search about the current situation.
I would suggest to increase TCP_SYN_RETRIES from 5 to 6.
180 secs is eternity, but 31 secs is too small.
Can you repost a v2, only changing TCP_SYN_RETRIES ?
^ permalink raw reply
* [PATCH v2] libceph: Fix sparse warning
From: Iulius Curt @ 2012-08-23 12:14 UTC (permalink / raw)
To: sage; +Cc: davem, ceph-devel, netdev, dbaluta, Iulius Curt, Iulius Curt
From: Iulius Curt <iulius.curt@gmail.com>
Make ceph_monc_do_poolop() static to remove the following sparse warning:
* net/ceph/mon_client.c:616:5: warning: symbol 'ceph_monc_do_poolop' was not
declared. Should it be static?
Also drops the 'ceph_monc_' prefix, now being a private function.
Signed-off-by: Iulius Curt <icurt@ixiacom.com>
---
v1 ---> v2
* drop the 'ceph_monc_' prefix
---
net/ceph/mon_client.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ceph/mon_client.c b/net/ceph/mon_client.c
index 105d533..84ce495 100644
--- a/net/ceph/mon_client.c
+++ b/net/ceph/mon_client.c
@@ -613,7 +613,7 @@ bad:
/*
* Do a synchronous pool op.
*/
-int ceph_monc_do_poolop(struct ceph_mon_client *monc, u32 op,
+static int do_poolop(struct ceph_mon_client *monc, u32 op,
u32 pool, u64 snapid,
char *buf, int len)
{
@@ -663,7 +663,7 @@ out:
int ceph_monc_create_snapid(struct ceph_mon_client *monc,
u32 pool, u64 *snapid)
{
- return ceph_monc_do_poolop(monc, POOL_OP_CREATE_UNMANAGED_SNAP,
+ return do_poolop(monc, POOL_OP_CREATE_UNMANAGED_SNAP,
pool, 0, (char *)snapid, sizeof(*snapid));
}
@@ -672,7 +672,7 @@ EXPORT_SYMBOL(ceph_monc_create_snapid);
int ceph_monc_delete_snapid(struct ceph_mon_client *monc,
u32 pool, u64 snapid)
{
- return ceph_monc_do_poolop(monc, POOL_OP_CREATE_UNMANAGED_SNAP,
+ return do_poolop(monc, POOL_OP_CREATE_UNMANAGED_SNAP,
pool, snapid, 0, 0);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH] netlink: fix possible spoofing from non-root processes
From: pablo @ 2012-08-23 12:09 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Pablo Neira Ayuso <pablo@netfilter.org>
Non-root user-space processes can send Netlink messages to other
processes that are well-known for being subscribed to Netlink
asynchronous notifications. This allows ilegitimate non-root
process to send forged messages to Netlink subscribers.
The userspace process usually verifies the legitimate origin in
two ways:
a) Socket credentials. If UID != 0, then the message comes from
some ilegitimate process and the message needs to be dropped.
b) Netlink portID. In general, portID == 0 means that the origin
of the messages comes from the kernel. Thus, discarding any
message not coming from the kernel.
However, ctnetlink sets the portID in event messages that has
been triggered by some user-space process, eg. conntrack utility.
So other processes subscribed to ctnetlink events, eg. conntrackd,
know that the event was triggered by some user-space action.
Neither of the two ways to discard ilegitimate messages coming
from non-root processes can help for ctnetlink.
This patch adds capability validation in case that dst_pid is set
in netlink_sendmsg(). This approach is aggressive since existing
applications using any Netlink bus to deliver messages between
two user-space processes will break. Note that the exception is
NETLINK_USERSOCK, since it is reserved for netlink-to-netlink
userspace communication.
Still, if anyone wants that his Netlink bus allows netlink-to-netlink
userspace, then they can set NL_NONROOT_SEND. However, by default,
I don't think it makes sense to allow to use NETLINK_ROUTE to
communicate two processes that are sending no matter what information
that is not related to link/neighbouring/routing. They should be using
NETLINK_USERSOCK instead for that.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netlink/af_netlink.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 5463969..998dd18 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1373,7 +1373,8 @@ static int netlink_sendmsg(struct kiocb *kiocb, struct socket *sock,
dst_pid = addr->nl_pid;
dst_group = ffs(addr->nl_groups);
err = -EPERM;
- if (dst_group && !netlink_capable(sock, NL_NONROOT_SEND))
+ if ((dst_group || dst_pid) &&
+ !netlink_capable(sock, NL_NONROOT_SEND))
goto out;
} else {
dst_pid = nlk->dst_pid;
@@ -2147,6 +2148,7 @@ static void __init netlink_add_usersock_entry(void)
rcu_assign_pointer(nl_table[NETLINK_USERSOCK].listeners, listeners);
nl_table[NETLINK_USERSOCK].module = THIS_MODULE;
nl_table[NETLINK_USERSOCK].registered = 1;
+ nl_table[NETLINK_USERSOCK].nl_nonroot = NL_NONROOT_SEND;
netlink_table_ungrab();
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 1/1] tcp: Wrong timeout for SYN segments
From: Alex Bergmann @ 2012-08-23 11:58 UTC (permalink / raw)
To: H.K. Jerry Chu; +Cc: davem, netdev, linux-kernel
In-Reply-To: <CAFbMe2M7ekc94bQk7vTS1LhScPd49VZ-zKOCUXhqwxXtL-nkuA@mail.gmail.com>
On 08/22/2012 06:41 PM, H.K. Jerry Chu wrote:
> On Tue, Aug 21, 2012 at 4:29 PM, Alex Bergmann <alex@linlab.net
> <mailto:alex@linlab.net>> wrote:
>
> Hi David,
>
> I'm not 100% sure, but it looks like I found an RFC mismatch with the
> current default values of the TCP implementation.
>
> Alex
>
> From 8b854a525eb45f64ad29dfab16f9d9f681e84495 Mon Sep 17 00:00:00 2001
> From: Alexander Bergmann <alex@linlab.net <mailto:alex@linlab.net>>
> Date: Wed, 22 Aug 2012 00:29:08 +0200
> Subject: [PATCH 1/1] tcp: Wrong timeout for SYN segments
>
> Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
> RFC6298 (former RFC2988bis). This introduced a gap with RFC1122 that
> defines a minimum retransmission window for SYN segments of at least
> 180secs.
>
> Prior to 9ad7c049 the timeout was defined with 189secs. Now we have only
> a timeout of 63secs.
>
> ((2 << 5) - 1) * 3 secs = 189 secs
> ((2 << 5) - 1) * 1 secs = 63 secs
>
> To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for
> SYN segments, the values of TCP_SYN_RETRIES and TCP_SYNACK_RETRIES must
> be changed to 7 reties.
>
> ((2 << 7) - 1) * 1 secs = 255 secs
>
> This would result in an ETIMEDOUT of 4 minutes 15 seconds.
>
>
> This issue occurred to me right after I submitted the patch for RFC6298.
> I did not commit any more change because RFC compliance aside, 180secs
> just seem like eternity in the Internet age.
>
> (See my past post on this at
> http://marc.info/?l=linux-netdev&m=130759078118866&w=2)
Okay, I missed that post during my search about the current situation.
Thanks,
Alex
> Jerry
>
>
> Signed-off-by: Alexander Bergmann <alex@linlab.net
> <mailto:alex@linlab.net>>
> ---
> include/net/tcp.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 1f000ff..7eaae19 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int
> state, int timeo);
> * 15 is ~13-30min depending on RTO.
> */
>
> -#define TCP_SYN_RETRIES 5 /* number of times to retry
> active opening a
> +#define TCP_SYN_RETRIES 7 /* number of times to retry
> active opening a
> * connection: ~180sec is RFC
> minimum */
>
> -#define TCP_SYNACK_RETRIES 5 /* number of times to retry passive
> opening a
> +#define TCP_SYNACK_RETRIES 7 /* number of times to retry passive
> opening a
> * connection: ~180sec is RFC
> minimum */
>
> #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy
> TIME-WAIT
> --
> 1.7.8.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> <mailto:majordomo@vger.kernel.org>
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
|. _ | _ |_ _ _ _|_
||| ||(_||_).| |(/_ |
email/sip/xmpp: alex@linlab.net
phone/enum: +49 2871 2355378
^ permalink raw reply
* [PATCH] af_packet: match_fanout_group() can be static
From: Fengguang Wu @ 2012-08-23 11:51 UTC (permalink / raw)
To: David Miller; +Cc: networking, Eric Leblond
cc: Eric Leblond <eric@regit.org>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
net/packet/af_packet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next.orig/net/packet/af_packet.c 2012-08-23 19:48:43.209188551 +0800
+++ linux-next/net/packet/af_packet.c 2012-08-23 19:48:53.413188794 +0800
@@ -1273,7 +1273,7 @@ static void __fanout_unlink(struct sock
spin_unlock(&f->lock);
}
-bool match_fanout_group(struct packet_type *ptype, struct sock * sk)
+static bool match_fanout_group(struct packet_type *ptype, struct sock * sk)
{
if (ptype->af_packet_priv == (void*)((struct packet_sock *)sk)->fanout)
return true;
^ permalink raw reply
* Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections
From: Eric Dumazet @ 2012-08-23 11:40 UTC (permalink / raw)
To: Pádraig Brady
Cc: Bruce "Brutus" Curtis, David S. Miller, Eric Dumazet,
netdev
In-Reply-To: <50360C81.6000009@draigBrady.com>
On Thu, 2012-08-23 at 11:57 +0100, Pádraig Brady wrote:
> Just to quantify the loopback testing compat issue.
> I often do stuff like the following to test latency.
> Will that be impacted?
>
> tc qdisc add dev lo root handle 1:0 netem delay 20msec
>
Yes this will. At least for tcp traffic this wont "work".
TCP friends bypass layers, by directly queuing skbs to sockets.
-> no iptables,
no qdisc (by default there is no qdisc on lo),
no loopback stats (ifconfig lo).
some SNMP stats missing as well (netstat -s)
> As for the stated tcpdump change,
> I don't suppose it would be possible to dynamically
> disable this (for new connections at least)
> while lo is being dumped?
This could be done, but it might be better to let the admin globally
enable/disable TCP friends...
^ permalink raw reply
* Re: [net-next 10/13] igb: Tidy up wrapping for CONFIG_IGB_PTP.
From: Richard Cochran @ 2012-08-23 11:28 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Matthew Vick, netdev, gospo, sassmann
In-Reply-To: <1345715813-20757-11-git-send-email-jeffrey.t.kirsher@intel.com>
On Thu, Aug 23, 2012 at 02:56:50AM -0700, Jeff Kirsher wrote:
> From: Matthew Vick <matthew.vick@intel.com>
>
> For users without CONFIG_IGB_PTP=y, we should not be compiling any PTP
> code into the driver. Tidy up the wrapping in igb to support this.
I would appreciate being put on Cc: for any PTP stuff.
Also, if you really want to improve the IGB driver, maybe you could
look at what happens to the time stamping when you do an ifdown/ifup
on the card. It seems to screw everything (observed on kernel 3.5).
Thanks,
Richard
^ permalink raw reply
* Re: [net-next 12/13] igb: Correct PTP support query from ethtool.
From: Richard Cochran @ 2012-08-23 11:24 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Matthew Vick, netdev, gospo, sassmann
In-Reply-To: <1345715813-20757-13-git-send-email-jeffrey.t.kirsher@intel.com>
On Thu, Aug 23, 2012 at 02:56:52AM -0700, Jeff Kirsher wrote:
> From: Matthew Vick <matthew.vick@intel.com>
>
> Update ethtool_get_ts_info to not report any supported functionality on
> 82575 and add support for V2 Sync and V2 Delay packets. In the case
> where CONFIG_IGB_PTP is not defined, we should be reporting default
> values.
> diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
...
> +#endif /* CONFIG_IGB_PTP */
> + default:
> + return ethtool_op_get_ts_info(dev, info);
This is wrong. Using this function advertises that you support SW TX
time stamps, which you do not.
Thanks,
Richard
> + break;
> + }
>
> return 0;
> }
> -#endif /* CONFIG_IGB_PTP */
>
> static int igb_ethtool_begin(struct net_device *netdev)
> {
> @@ -2351,9 +2368,7 @@ static const struct ethtool_ops igb_ethtool_ops = {
> .get_ethtool_stats = igb_get_ethtool_stats,
> .get_coalesce = igb_get_coalesce,
> .set_coalesce = igb_set_coalesce,
> -#ifdef CONFIG_IGB_PTP
> .get_ts_info = igb_get_ts_info,
> -#endif /* CONFIG_IGB_PTP */
> .begin = igb_ethtool_begin,
> .complete = igb_ethtool_complete,
> };
> --
> 1.7.11.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next 11/13] igb: Update PTP function names/variables and locations.
From: Richard Cochran @ 2012-08-23 11:16 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Matthew Vick, netdev, gospo, sassmann
In-Reply-To: <1345715813-20757-12-git-send-email-jeffrey.t.kirsher@intel.com>
On Thu, Aug 23, 2012 at 02:56:51AM -0700, Jeff Kirsher wrote:
> From: Matthew Vick <matthew.vick@intel.com>
>
> Where possible, move PTP-related functions into igb_ptp.c and update the
> names of functions and variables to match the established coding style
> in the files and specify that they are PTP-specific.
Function renaming as an end in itself? Sounds like churn to me. Also,
I disagree with some of the displacements.
> diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> index 6adb0f7..d1a120e 100644
> --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> @@ -2280,21 +2280,8 @@ static void igb_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
> }
> }
>
> -static int igb_ethtool_begin(struct net_device *netdev)
> -{
> - struct igb_adapter *adapter = netdev_priv(netdev);
> - pm_runtime_get_sync(&adapter->pdev->dev);
> - return 0;
> -}
> -
> -static void igb_ethtool_complete(struct net_device *netdev)
> -{
> - struct igb_adapter *adapter = netdev_priv(netdev);
> - pm_runtime_put(&adapter->pdev->dev);
> -}
> -
Why have you moved this block? How are these "PTP-related"?
> #ifdef CONFIG_IGB_PTP
> -static int igb_ethtool_get_ts_info(struct net_device *dev,
> +static int igb_get_ts_info(struct net_device *dev,
I like the old name better.
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
...
> -#ifdef CONFIG_IGB_PTP
> -/**
> - * igb_tx_hwtstamp - utility function which checks for TX time stamp
> - * @q_vector: pointer to q_vector containing needed info
> - * @buffer: pointer to igb_tx_buffer structure
> - *
> - * If we were asked to do hardware stamping and such a time stamp is
> - * available, then it must have been for this skb here because we only
> - * allow only one such packet into the queue.
> - */
> -static void igb_tx_hwtstamp(struct igb_q_vector *q_vector,
> - struct igb_tx_buffer *buffer_info)
> -{
> - struct igb_adapter *adapter = q_vector->adapter;
> - struct e1000_hw *hw = &adapter->hw;
> - struct skb_shared_hwtstamps shhwtstamps;
> - u64 regval;
> -
> - /* if skb does not support hw timestamp or TX stamp not valid exit */
> - if (likely(!(buffer_info->tx_flags & IGB_TX_FLAGS_TSTAMP)) ||
> - !(rd32(E1000_TSYNCTXCTL) & E1000_TSYNCTXCTL_VALID))
> - return;
> -
> - regval = rd32(E1000_TXSTMPL);
> - regval |= (u64)rd32(E1000_TXSTMPH) << 32;
> -
> - igb_systim_to_hwtstamp(adapter, &shhwtstamps, regval);
> - skb_tstamp_tx(buffer_info->skb, &shhwtstamps);
> -}
> -#endif /* CONFIG_IGB_PTP */
> -
Here you have taken a static local function and made it into a global
function. This can have performance impacts.
> /**
> * igb_clean_tx_irq - Reclaim resources after transmit completes
> * @q_vector: pointer to q_vector containing needed info
> @@ -5827,7 +5796,7 @@ static bool igb_clean_tx_irq(struct igb_q_vector *q_vector)
>
> #ifdef CONFIG_IGB_PTP
> /* retrieve hardware timestamp */
> - igb_tx_hwtstamp(q_vector, tx_buffer);
> + igb_ptp_tx_hwtstamp(q_vector, tx_buffer);
This name stinks, too. You know that you can have time stamping all by
itself, right? It is logically separate from the ptp clock stuff.
This patch doesn't really improve the driver at all, IMHO.
Thanks,
Richard
^ permalink raw reply
* Re: [net-next 10/13] igb: Tidy up wrapping for CONFIG_IGB_PTP.
From: Richard Cochran @ 2012-08-23 11:03 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Matthew Vick, netdev, gospo, sassmann
In-Reply-To: <1345715813-20757-11-git-send-email-jeffrey.t.kirsher@intel.com>
On Thu, Aug 23, 2012 at 02:56:50AM -0700, Jeff Kirsher wrote:
> From: Matthew Vick <matthew.vick@intel.com>
>
> For users without CONFIG_IGB_PTP=y, we should not be compiling any PTP
> code into the driver. Tidy up the wrapping in igb to support this.
Actually, you are doing more than that. You are adding a bunch of
comments onto the already existing #endifs.
> Signed-off-by: Matthew Vick <matthew.vick@intel.com>
> Acked-by: Jacob Keller <jacob.e.keller@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/igb/igb.h | 8 ++++++--
> drivers/net/ethernet/intel/igb/igb_ethtool.c | 4 ++--
> drivers/net/ethernet/intel/igb/igb_main.c | 23 +++++++++++++++++------
> 3 files changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
> index 0c9f62c..a3b5b90 100644
> --- a/drivers/net/ethernet/intel/igb/igb.h
> +++ b/drivers/net/ethernet/intel/igb/igb.h
> @@ -34,9 +34,11 @@
> #include "e1000_mac.h"
> #include "e1000_82575.h"
>
> +#ifdef CONFIG_IGB_PTP
> #include <linux/clocksource.h>
> #include <linux/net_tstamp.h>
> #include <linux/ptp_clock_kernel.h>
> +#endif /* CONFIG_IGB_PTP */
> #include <linux/bitops.h>
> #include <linux/if_vlan.h>
>
> @@ -376,12 +378,15 @@ struct igb_adapter {
> int node;
> u32 *shadow_vfta;
>
> +#ifdef CONFIG_IGB_PTP
> struct ptp_clock *ptp_clock;
> struct ptp_clock_info caps;
> struct delayed_work overflow_work;
> spinlock_t tmreg_lock;
> struct cyclecounter cc;
> struct timecounter tc;
> +#endif /* CONFIG_IGB_PTP */
> +
This is legitimate, to reduce memory footprint.
> char fw_version[32];
> };
>
> @@ -436,12 +441,11 @@ extern void igb_set_fw_version(struct igb_adapter *);
> #ifdef CONFIG_IGB_PTP
> extern void igb_ptp_init(struct igb_adapter *adapter);
> extern void igb_ptp_remove(struct igb_adapter *adapter);
> -
> extern void igb_systim_to_hwtstamp(struct igb_adapter *adapter,
> struct skb_shared_hwtstamps *hwtstamps,
> u64 systim);
> +#endif /* CONFIG_IGB_PTP */
>
> -#endif
> static inline s32 igb_reset_phy(struct e1000_hw *hw)
> {
> if (hw->phy.ops.reset)
> diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> index c4def55..6adb0f7 100644
> --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> @@ -2323,8 +2323,8 @@ static int igb_ethtool_get_ts_info(struct net_device *dev,
>
> return 0;
> }
> +#endif /* CONFIG_IGB_PTP */
>
> -#endif
> static const struct ethtool_ops igb_ethtool_ops = {
> .get_settings = igb_get_settings,
> .set_settings = igb_set_settings,
> @@ -2355,7 +2355,7 @@ static const struct ethtool_ops igb_ethtool_ops = {
> .complete = igb_ethtool_complete,
> #ifdef CONFIG_IGB_PTP
> .get_ts_info = igb_ethtool_get_ts_info,
> -#endif
> +#endif /* CONFIG_IGB_PTP */
> };
>
> void igb_set_ethtool_ops(struct net_device *netdev)
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
> index 73cc273..03477d7 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -2180,11 +2180,12 @@ static int __devinit igb_probe(struct pci_dev *pdev,
> }
>
> #endif
> +
> #ifdef CONFIG_IGB_PTP
> /* do hw tstamp init after resetting */
> igb_ptp_init(adapter);
> +#endif /* CONFIG_IGB_PTP */
>
> -#endif
But this is just churn. You aren't actually improving anything
here. It is already clear that the #endif belongs to the #ifdef just
three lines above.
If you are on some kind of campaign to comment all the endifs, then
you should say so, and, to be consistent, you should not overlook the
CONFIG_IGB_DCA blocks.
But I think it really isn't needed.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections
From: Pádraig Brady @ 2012-08-23 10:57 UTC (permalink / raw)
To: Bruce "Brutus" Curtis; +Cc: David S. Miller, Eric Dumazet, netdev
In-Reply-To: <1344559958-29162-1-git-send-email-brutus@google.com>
On 08/10/2012 01:52 AM, Bruce "Brutus" Curtis wrote:
> From: "Bruce \"Brutus\" Curtis" <brutus@google.com>
>
> TCP/IP loopback socket pair stack bypass, based on an idea by, and
> rough upstream patch from, David Miller <davem@davemloft.net> called
> "friends", the data structure modifcations and connection scheme are
> reused with extensive data-path changes.
>
> A new sysctl, net.ipv4.tcp_friends, is added:
> 0: disable friends and use the stock data path.
> 1: enable friends and bypass the stack data path, the default.
>
> Note, when friends is enabled any loopback interpose, e.g. tcpdump,
> will only see the TCP/IP packets during connection establishment and
> finish, all data bypasses the stack and instead is delivered to the
> destination socket directly.
>
> Testing done on a 4 socket 2.2GHz "Quad-Core AMD Opteron(tm) Processor
> 8354 CPU" based system, netperf results for a single connection show
> increased TCP_STREAM throughput, increased TCP_RR and TCP_CRR transaction
> rate for most message sizes vs baseline and comparable to AF_UNIX.
>
> Significant increase (up to 4.88x) in aggregate throughput for multiple
> netperf runs (STREAM 32KB I/O x N) is seen.
Nice!
Just to quantify the loopback testing compat issue.
I often do stuff like the following to test latency.
Will that be impacted?
tc qdisc add dev lo root handle 1:0 netem delay 20msec
As for the stated tcpdump change,
I don't suppose it would be possible to dynamically
disable this (for new connections at least)
while lo is being dumped?
cheers,
Pádraig.
^ permalink raw reply
* Re: [net-next 13/13] igb: Store the MAC address in the name in the PTP struct.
From: Richard Cochran @ 2012-08-23 10:45 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Matthew Vick, netdev, gospo, sassmann
In-Reply-To: <1345715813-20757-14-git-send-email-jeffrey.t.kirsher@intel.com>
On Thu, Aug 23, 2012 at 02:56:53AM -0700, Jeff Kirsher wrote:
> From: Matthew Vick <matthew.vick@intel.com>
>
> Change the name of the adapter in the PTP struct to enable easier
> correlation between interface and PTP device.
You want to put the MAC address into the clock name? This is wrong.
Besides, there is no need for this. The ethool method already makes
the correlation crystal clear.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH v6] bonding support for IPv6 transmit hashing
From: Jeremy Brookman @ 2012-08-23 10:42 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: linux, netdev
In-Reply-To: <11100.1345576795@death.nxdomain>
Hi,
A few questions on the actual patch inline now I've had a bit more time...
> static int bond_xmit_hash_policy_l23(struct sk_buff *skb, int count)
...
> + if (skb->protocol == htons(ETH_P_IP) &&
> + skb_network_header_len(skb) >= sizeof(struct iphdr)) {
> + iph = ip_hdr(skb);
> return ((ntohl(iph->saddr ^ iph->daddr) & 0xffff) ^
> (data->h_dest[5] ^ data->h_source[5])) % count;
> + } else if (skb->protocol == htons(ETH_P_IPV6) &&
> + skb_network_header_len(skb) >= sizeof(struct ipv6hdr)) {
> + ipv6h = ipv6_hdr(skb);
> + s = &ipv6h->saddr.s6_addr32[0];
> + d = &ipv6h->daddr.s6_addr32[0];
> + v6hash = (s[1] ^ d[1]) ^ (s[2] ^ d[2]) ^ (s[3] ^ d[3]);
> + v6hash ^= (v6hash >> 24) ^ (v6hash >> 16) ^ (v6hash >> 8);
> + return (v6hash ^ data->h_dest[5] ^ data->h_source[5]) % count;
> }
>
If the IPv4 case needs an ntohl, does the IPv6 case (if we're
interpreting the address as 4 32-bits)? If IPv4 hashing algorithm is
consistent across different endiannesses, then maybe IPv6 should be
too?
> /*
> * Hash for the output device based upon layer 3 and layer 4 data. If
> * the packet is a frag or not TCP or UDP, just use layer 3 data. If it is
> - * altogether not IP, mimic bond_xmit_hash_policy_l2()
> + * altogether not IP, fall back on bond_xmit_hash_policy_l2()
> */
Looking at the code below, we only check the first value of next_hdr
in the chain; however RFC 2460 lists the following possible extension
headers, all of which will therefore cause fallback to L3 hashing:
Hop-by-Hop Options
Routing (Type 0)
Fragment
Destination Options
Authentication
Encapsulating Security Payload
Clearly with some (eg ESP and fragment) we do need to drop out of
using L4 header info in the hash. And anyone using Routing (Type 0)
probably deserves anything they get. But should we at least comment
on the limitation that the existence of the other headers also causes
fallback to L3 hashing only? (And possibly even include in
documentation?) Or of course, fix?
> if (skb->protocol == htons(ETH_P_IP)) {
> + iph = ip_hdr(skb);
> if (!ip_is_fragment(iph) &&
> (iph->protocol == IPPROTO_TCP ||
> iph->protocol == IPPROTO_UDP)) {
> + if (iph->ihl * sizeof(u32) + sizeof(__be16) * 2 >
> + skb_headlen(skb) - skb_network_offset(skb))
> + goto short_header;
> + layer4hdr = (__be16 *)((u32 *)iph + iph->ihl);
> layer4_xor = ntohs((*layer4hdr ^ *(layer4hdr + 1)));
> + } else if (skb_network_header_len(skb) < sizeof(struct iphdr)) {
> + goto short_header;
> }
I don't know the assertions we can make about
skb_network_header_len(skb), but it looks odd doing a length check
against sizeof(iphdr) after iph->protocol has already been
dereferenced. Is this really right? (The pattern recurs a few times.)
Regards,
Jeremy
^ permalink raw reply
* Re: wireless router performance differ with 2.4Ghz vs 5.0Ghz frequency
From: Julian Calaby @ 2012-08-23 10:34 UTC (permalink / raw)
To: Lin Ming; +Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, networking
In-Reply-To: <CAF1ivSZ63Zr9STz3NnLV=ynRftMokG=ZGghd+cQu=HRUsiH+EA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On Thu, Aug 23, 2012 at 2:50 PM, Lin Ming <mlin-H0MqCF3V8pkCalJqGWEchg@public.gmane.org> wrote:
> Hi list,
>
> I have a wireless router with 2 wireless cards: 2.4Ghz and 5.0Ghz frequency.
>
> The performance for 2.4Ghz is much worse than 5.0Ghz.
>
> Does the frequency affect performance so much?
There are a lot of factors:
- Amounts of other networks on the same channel
- Noise
- Signal strength
etc.
It's quite possible that there are less networks on 5GHz channels
where you are so there's less noise, stronger signal, and therefore
better performance. Most routers are still only 2.4GHz.
Thanks,
--
Julian Calaby
Email: julian.calaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 v2] net: add new QCA alx ethernet driver
From: Luis R. Rodriguez @ 2012-08-23 10:28 UTC (permalink / raw)
To: David Miller
Cc: xiong, cjren, netdev, linux-kernel, qca-linux-team, nic-devel,
Adrian Chadd, Vinod Nagarajan, Julia Lawall, Lisong Guo
In-Reply-To: <20120823.001342.959509094678320374.davem@davemloft.net>
On Thu, Aug 23, 2012 at 11:13 AM, David Miller <davem@davemloft.net> wrote:
> From: "Huang, Xiong" <xiong@qca.qualcomm.com>
> Date: Thu, 23 Aug 2012 06:56:51 +0000
>
>> I'm afraid someone also rejects my request to add such operation to
>> ethtool
>
> If you don't design it properly, we certainly will ask you to make
> changes.
>
> But it stands a chance of actually being accepted, whereas your
> debugfs thing absolutely does not.
Xiong, you can dump that poo and put it into crap/ in compat-drivers
until you find a resolution to properly address that properly.
FWIW... if we give a rats ass on trying to put an end typical internal
proprietary development trees to port drivers to different OSes [0]
here's a cheesy attempt to try address this with a target for Linux
and FreeBSD as a first objective:
https://github.com/mcgrof/alx
The goal would be to push companies to do their bringup development
*openly* and even if they do have support for other OSes, for that poo
to also be public. The alx driver is a dead simple so my if at all
possible to show a *different* community-lead way to port drivers and
for this poo to be public my hope is that the alx driver can be the
test case for us to try it on.
Xiong, and whoever cares please think about it. I welcome feedback from others.
[0] http://www.youtube.com/watch?v=9P-r3H0bY8c
Luis
^ 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