* Re: [PATCH net-next 2/2] include/uapi/linux/xfrm.h: Pack struct xfrm_usersa_info
From: Ben Hutchings @ 2014-01-08 20:33 UTC (permalink / raw)
To: Fan Du; +Cc: steffen.klassert, davem, stephen, dev, netdev
In-Reply-To: <1389077339-12814-3-git-send-email-fan.du@windriver.com>
On Tue, 2014-01-07 at 14:48 +0800, Fan Du wrote:
> Otherwise 64bits kernel has sizeof(struct xfrm_usersa_info) 224 bytes,
> while 32bits compiled iproute2 see the same structure as 220 bytes, which
> leading deficit xfrm sa, in turn broken IPsec connectivity.
>
> Fix this by packing the structure.
>
> Signed-off-by: Fan Du <fan.du@windriver.com>
> ---
> include/uapi/linux/xfrm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/xfrm.h b/include/uapi/linux/xfrm.h
> index 470bfae..61460c4 100644
> --- a/include/uapi/linux/xfrm.h
> +++ b/include/uapi/linux/xfrm.h
> @@ -366,7 +366,7 @@ struct xfrm_usersa_info {
> #define XFRM_STATE_AF_UNSPEC 32
> #define XFRM_STATE_ALIGN4 64
> #define XFRM_STATE_ESN 128
> -};
> +} __attribute__((packed));
>
> #define XFRM_SA_XFLAG_DONT_ENCAP_DSCP 1
>
That change will make access to the structure very slow on some
architectures, and I suspect it will cause other compatibility problems.
I think the right thing to do is to reduce the minimum length of the
structure in the netlink policy so that padding at the end is not
required. (It looks like all field offsets will be the same on all
32/64-bit architecture pairs and there is only a differing amount of
padding at the end of the structure for 32/64-bit alignment.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-next V3 3/3] net: Add GRO support for vxlan traffic
From: Or Gerlitz @ 2014-01-08 20:34 UTC (permalink / raw)
To: hkchu, edumazet, herbert; +Cc: netdev, davem, yanb, shlomop, Or Gerlitz
In-Reply-To: <1389213278-2200-1-git-send-email-ogerlitz@mellanox.com>
Add gro handlers for vxlan using the udp gro infrastructure
On my setup, which is net-next (now with the mlx4 vxlan offloads patches) --
for single TCP session that goes through vxlan tunneling I got nice improvement
from 6.8Gbs to 11.5Gbs
--> UDP/VXLAN GRO disabled
$ netperf -H 192.168.52.147 -c -C
$ netperf -t TCP_STREAM -H 192.168.52.147 -c -C
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.52.147 () port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 65536 65536 10.00 6799.75 12.54 24.79 0.604 1.195
--> UDP/VXLAN GRO enabled
$ netperf -t TCP_STREAM -H 192.168.52.147 -c -C
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.52.147 () port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 65536 65536 10.00 11562.72 24.90 20.34 0.706 0.577
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/vxlan.c | 129 ++++++++++++++++++++++++++++++++++++++++++++++++---
include/net/vxlan.h | 1 +
2 files changed, 123 insertions(+), 7 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 481f85d..e132f19 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -40,6 +40,7 @@
#include <net/net_namespace.h>
#include <net/netns/generic.h>
#include <net/vxlan.h>
+#include <net/protocol.h>
#if IS_ENABLED(CONFIG_IPV6)
#include <net/ipv6.h>
#include <net/addrconf.h>
@@ -554,10 +555,111 @@ static int vxlan_fdb_append(struct vxlan_fdb *f,
return 1;
}
+static struct sk_buff **vxlan_gro_receive(struct sk_buff **head, struct sk_buff *skb)
+{
+ struct sk_buff *p, **pp = NULL;
+ struct vxlanhdr *vh, *vh2;
+ struct ethhdr *eh, *eh2;
+ unsigned int hlen, off_vx, off_eth;
+ const struct packet_offload *ptype;
+ __be16 type;
+ int flush = 1;
+
+ off_vx = skb_gro_offset(skb);
+ hlen = off_vx + sizeof(*vh);
+ vh = skb_gro_header_fast(skb, off_vx);
+ if (skb_gro_header_hard(skb, hlen)) {
+ vh = skb_gro_header_slow(skb, hlen, off_vx);
+ if (unlikely(!vh))
+ goto out;
+ }
+ skb_gro_pull(skb, sizeof(struct vxlanhdr)); /* pull vxlan header */
+
+ off_eth = skb_gro_offset(skb);
+ hlen = off_eth + sizeof(*eh);
+ eh = skb_gro_header_fast(skb, off_eth);
+ if (skb_gro_header_hard(skb, hlen)) {
+ eh = skb_gro_header_slow(skb, hlen, off_eth);
+ if (unlikely(!eh))
+ goto out;
+ }
+
+ flush = 0;
+
+ for (p = *head; p; p = p->next) {
+ if (!NAPI_GRO_CB(p)->same_flow)
+ continue;
+
+ vh2 = (struct vxlanhdr *)(p->data + off_vx);
+ eh2 = (struct ethhdr *)(p->data + off_eth);
+ if (vh->vx_vni != vh2->vx_vni || compare_ether_header(eh, eh2)) {
+ NAPI_GRO_CB(p)->same_flow = 0;
+ continue;
+ }
+ goto found;
+ }
+
+found:
+ type = eh->h_proto;
+
+ rcu_read_lock();
+ ptype = gro_find_receive_by_type(type);
+ if (ptype == NULL) {
+ flush = 1;
+ goto out_unlock;
+ }
+
+ skb_gro_pull(skb, sizeof(*eh)); /* pull inner eth header */
+ pp = ptype->callbacks.gro_receive(head, skb);
+
+out_unlock:
+ rcu_read_unlock();
+out:
+ NAPI_GRO_CB(skb)->flush |= flush;
+
+ return pp;
+}
+
+static int vxlan_gro_complete(struct sk_buff *skb, int nhoff)
+{
+ struct ethhdr *eh;
+ struct packet_offload *ptype;
+ __be16 type;
+ /* 22 = 8 bytes for the vlxan header + 14 bytes for the inner eth header */
+ int vxlan_len = 22;
+ int err = -ENOSYS;
+
+ eh = (struct ethhdr *)(skb->data + nhoff + sizeof (struct vxlanhdr));
+ type = eh->h_proto;
+
+ rcu_read_lock();
+ ptype = gro_find_complete_by_type(type);
+ if (ptype != NULL)
+ err = ptype->callbacks.gro_complete(skb, nhoff + vxlan_len);
+
+ rcu_read_unlock();
+ return err;
+}
+
+static void vxlan_add_udp_offload(struct rcu_head *head)
+{
+ struct vxlan_sock *vs = container_of(head, struct vxlan_sock, rcu);
+
+ udp_add_offload(&vs->udp_offloads);
+}
+
+static void vxlan_del_udp_offload(struct rcu_head *head)
+{
+ struct vxlan_sock *vs = container_of(head, struct vxlan_sock, rcu);
+
+ udp_del_offload(&vs->udp_offloads);
+}
+
/* Notify netdevs that UDP port started listening */
-static void vxlan_notify_add_rx_port(struct sock *sk)
+static void vxlan_notify_add_rx_port(struct vxlan_sock *vs)
{
struct net_device *dev;
+ struct sock *sk = vs->sock->sk;
struct net *net = sock_net(sk);
sa_family_t sa_family = sk->sk_family;
__be16 port = inet_sk(sk)->inet_sport;
@@ -569,12 +671,16 @@ static void vxlan_notify_add_rx_port(struct sock *sk)
port);
}
rcu_read_unlock();
+
+ if (sa_family == AF_INET)
+ call_rcu(&vs->rcu, vxlan_add_udp_offload);
}
/* Notify netdevs that UDP port is no more listening */
-static void vxlan_notify_del_rx_port(struct sock *sk)
+static void vxlan_notify_del_rx_port(struct vxlan_sock *vs)
{
struct net_device *dev;
+ struct sock *sk = vs->sock->sk;
struct net *net = sock_net(sk);
sa_family_t sa_family = sk->sk_family;
__be16 port = inet_sk(sk)->inet_sport;
@@ -586,6 +692,9 @@ static void vxlan_notify_del_rx_port(struct sock *sk)
port);
}
rcu_read_unlock();
+
+ if (sa_family == AF_INET)
+ call_rcu(&vs->rcu, vxlan_del_udp_offload);
}
/* Add new entry to forwarding table -- assumes lock held */
@@ -964,7 +1073,7 @@ void vxlan_sock_release(struct vxlan_sock *vs)
spin_lock(&vn->sock_lock);
hlist_del_rcu(&vs->hlist);
rcu_assign_sk_user_data(vs->sock->sk, NULL);
- vxlan_notify_del_rx_port(sk);
+ vxlan_notify_del_rx_port(vs);
spin_unlock(&vn->sock_lock);
queue_work(vxlan_wq, &vs->del_work);
@@ -1125,8 +1234,8 @@ static void vxlan_rcv(struct vxlan_sock *vs,
* leave the CHECKSUM_UNNECESSARY, the device checksummed it
* for us. Otherwise force the upper layers to verify it.
*/
- if (skb->ip_summed != CHECKSUM_UNNECESSARY || !skb->encapsulation ||
- !(vxlan->dev->features & NETIF_F_RXCSUM))
+ if ((skb->ip_summed != CHECKSUM_UNNECESSARY && skb->ip_summed != CHECKSUM_PARTIAL) ||
+ !skb->encapsulation || !(vxlan->dev->features & NETIF_F_RXCSUM))
skb->ip_summed = CHECKSUM_NONE;
skb->encapsulation = 0;
@@ -2304,7 +2413,7 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
struct sock *sk;
unsigned int h;
- vs = kmalloc(sizeof(*vs), GFP_KERNEL);
+ vs = kzalloc(sizeof(*vs), GFP_KERNEL);
if (!vs)
return ERR_PTR(-ENOMEM);
@@ -2329,9 +2438,15 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
vs->data = data;
rcu_assign_sk_user_data(vs->sock->sk, vs);
+ /* Initialize the vxlan udp offloads structure */
+ vs->udp_offloads.port = port;
+ vs->udp_offloads.callbacks.gro_receive = vxlan_gro_receive;
+ vs->udp_offloads.callbacks.gro_complete = vxlan_gro_complete;
+ INIT_LIST_HEAD(&vs->udp_offloads.list);
+
spin_lock(&vn->sock_lock);
hlist_add_head_rcu(&vs->hlist, vs_head(net, port));
- vxlan_notify_add_rx_port(sk);
+ vxlan_notify_add_rx_port(vs);
spin_unlock(&vn->sock_lock);
/* Mark socket as an encapsulation socket. */
diff --git a/include/net/vxlan.h b/include/net/vxlan.h
index 6b6d180..5deef1a 100644
--- a/include/net/vxlan.h
+++ b/include/net/vxlan.h
@@ -21,6 +21,7 @@ struct vxlan_sock {
struct rcu_head rcu;
struct hlist_head vni_list[VNI_HASH_SIZE];
atomic_t refcnt;
+ struct udp_offload udp_offloads;
};
struct vxlan_sock *vxlan_sock_add(struct net *net, __be16 port,
--
1.7.1
^ permalink raw reply related
* [PATCH net-next V3 0/3] net: Add GRO support for UDP encapsulating protocols
From: Or Gerlitz @ 2014-01-08 20:34 UTC (permalink / raw)
To: hkchu, edumazet, herbert; +Cc: netdev, davem, yanb, shlomop, Or Gerlitz
This series adds GRO handlers for protocols that do UDP encapsulation, with the
intent of being able to coalesce packets which encapsulate packets belonging to
the same TCP session.
For GRO purposes, the destination UDP port takes the role of the ether type
field in the ethernet header or the next protocol in the IP header.
The UDP GRO handler will only attempt to coalesce packets whose destination
port is registered to have gro handler.
On my setup, which is net-next (now with the mlx4 vxlan offloads patches) --
for single TCP session that goes through vxlan tunneling I got nice improvement
from 6.8Gbs to 11.5Gbs
patches done against net-next 80077935cad "Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next"
v2 --> v3 changes:
- moved to use linked list to store the udp gro handlers, this solves the
problem of consuming 512KB of memory for the handlers.
- use a mark on the skb GRO CB data to disallow running the udp gro_receive twice
on a packet, this solves the problem of udp encapsulated packets whose inner VM
packet is udp and happen to carry a port which has registered offloads - and flush it.
- invoke the udp offload protocol registration and de-registration from the vxlan driver
in a sleepable context
For unclear some reason I got this warning when the vxlan driver deletes the
udp offload structure
-----------[ cut here ]------------
WARNING: CPU: 2 PID: 19 at kernel/rcu/tree.c:2127 rcu_do_batch+0x359/0x370()
Modules linked in: veth vxlan ip_tunnel bridge stp llc rdma_ucm rdma_cm ib_cm iw_cm ib_addr ib_uverbs ib_umad mlx4_en ptp pps_core mlx4_ib ib_sa ib_mad ib_core mlx4_core nfsv3 nfs_acl auth_rpcgss oid_registry nfsv4 nfs lockd autofs4 sunrpc ipv6 dm_mirror dm_region_hash dm_log dm_mod joydev microcode pcspkr virtio_balloon virtio_net i2c_piix4 button ext3 jbd virtio_pci virtio_ring virtio uhci_hcd [last unloaded: ib_core]
CPU: 2 PID: 19 Comm: rcuc/2 Not tainted 3.13.0-rc6+ #278
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
000000000000084f ffff88021651dd68 ffffffff81498b52 000000000000084f
0000000000000000 ffff88021651dda8 ffffffff81059f2c ffff88021651dd98
ffff88022010d6a0 ffff88022010d6c8 0000000000000246 ffffffff81844200
Call Trace:
[<ffffffff81498b52>] dump_stack+0x51/0x77
[<ffffffff81059f2c>] warn_slowpath_common+0x8c/0xc0
[<ffffffff81059f7a>] warn_slowpath_null+0x1a/0x20
[<ffffffff810a49c9>] rcu_do_batch+0x359/0x370
[<ffffffff810a4ade>] rcu_cpu_kthread+0xfe/0x2b0
[<ffffffff81083697>] smpboot_thread_fn+0x167/0x260
[<ffffffff81083530>] ? smpboot_create_threads+0x80/0x80
[<ffffffff8107c36e>] kthread+0xce/0xf0
[<ffffffff8107c2a0>] ? kthread_freezable_should_stop+0x70/0x70
[<ffffffff8149de7c>] ret_from_fork+0x7c/0xb0
[<ffffffff8107c2a0>] ? kthread_freezable_should_stop+0x70/0x70
---[ end trace f98588ea45ef3f4c ]---
Or
Or Gerlitz (3):
net: Add GRO support for UDP encapsulating protocols
net: Export gro_find_by_type helpers
net: Add GRO support for vxlan traffic
drivers/net/vxlan.c | 129 ++++++++++++++++++++++++++++++++++++++++++---
include/linux/netdevice.h | 10 +++-
include/net/protocol.h | 3 +
include/net/vxlan.h | 1 +
net/core/dev.c | 3 +
net/ipv4/udp_offload.c | 129 +++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 267 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATCH net-next V3 1/3] net: Add GRO support for UDP encapsulating protocols
From: Or Gerlitz @ 2014-01-08 20:34 UTC (permalink / raw)
To: hkchu, edumazet, herbert; +Cc: netdev, davem, yanb, shlomop, Or Gerlitz
In-Reply-To: <1389213278-2200-1-git-send-email-ogerlitz@mellanox.com>
Add GRO handlers for protocols that do UDP encapsulation, with the intent of
being able to coalesce packets which encapsulate packets belonging to
the same TCP session.
For GRO purposes, the destination UDP port takes the role of the ether type
field in the ethernet header or the next protocol in the IP header.
The UDP GRO handler will only attempt to coalesce packets whose destination
port is registered to have gro handler.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
include/linux/netdevice.h | 10 +++-
include/net/protocol.h | 3 +
net/core/dev.c | 1 +
net/ipv4/udp_offload.c | 129 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 142 insertions(+), 1 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index a2a70cc..360551a 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1652,7 +1652,9 @@ struct napi_gro_cb {
unsigned long age;
/* Used in ipv6_gro_receive() */
- int proto;
+ u16 proto;
+
+ u16 udp_mark;
/* used to support CHECKSUM_COMPLETE for tunneling protocols */
__wsum csum;
@@ -1691,6 +1693,12 @@ struct packet_offload {
struct list_head list;
};
+struct udp_offload {
+ __be16 port;
+ struct offload_callbacks callbacks;
+ struct list_head list;
+};
+
/* often modified stats are per cpu, other are shared (netdev->stats) */
struct pcpu_sw_netstats {
u64 rx_packets;
diff --git a/include/net/protocol.h b/include/net/protocol.h
index fbf7676..fe9af94 100644
--- a/include/net/protocol.h
+++ b/include/net/protocol.h
@@ -103,6 +103,9 @@ int inet_del_offload(const struct net_offload *prot, unsigned char num);
void inet_register_protosw(struct inet_protosw *p);
void inet_unregister_protosw(struct inet_protosw *p);
+void udp_add_offload(struct udp_offload *prot);
+void udp_del_offload(struct udp_offload *prot);
+
#if IS_ENABLED(CONFIG_IPV6)
int inet6_add_protocol(const struct inet6_protocol *prot, unsigned char num);
int inet6_del_protocol(const struct inet6_protocol *prot, unsigned char num);
diff --git a/net/core/dev.c b/net/core/dev.c
index ce01847..11f7acf 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3858,6 +3858,7 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
NAPI_GRO_CB(skb)->same_flow = 0;
NAPI_GRO_CB(skb)->flush = 0;
NAPI_GRO_CB(skb)->free = 0;
+ NAPI_GRO_CB(skb)->udp_mark = 0;
pp = ptype->callbacks.gro_receive(&napi->gro_list, skb);
break;
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 79c62bd..2846ade 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -13,6 +13,16 @@
#include <linux/skbuff.h>
#include <net/udp.h>
#include <net/protocol.h>
+/*
+struct udp_offload {
+ __be16 port;
+ struct offload_callbacks callbacks;
+ struct list_head list;
+};
+*/
+
+static DEFINE_SPINLOCK(udp_offload_lock);
+static struct list_head udp_offload_base __read_mostly;
static int udp4_ufo_send_check(struct sk_buff *skb)
{
@@ -89,14 +99,133 @@ out:
return segs;
}
+void udp_add_offload(struct udp_offload *uo)
+{
+ struct list_head *head = &udp_offload_base;
+
+ spin_lock(&udp_offload_lock);
+ list_add_rcu(&uo->list, head);
+ spin_unlock(&udp_offload_lock);
+}
+EXPORT_SYMBOL(udp_add_offload);
+
+void udp_del_offload(struct udp_offload *uo)
+{
+ struct list_head *head = &udp_offload_base;
+ struct udp_offload *uo1;
+
+ spin_lock(&udp_offload_lock);
+ list_for_each_entry(uo1, head, list) {
+ if (uo == uo1) {
+ list_del_rcu(&uo->list);
+ goto out;
+ }
+ }
+
+ pr_warn("udp_remove_offload: %p not found port %d\n", uo, htons(uo->port));
+out:
+ spin_unlock(&udp_offload_lock);
+
+ synchronize_net();
+}
+EXPORT_SYMBOL(udp_del_offload);
+
+static struct sk_buff **udp_gro_receive(struct sk_buff **head, struct sk_buff *skb)
+{
+ struct list_head *ohead = &udp_offload_base;
+ struct udp_offload *poffload;
+ struct sk_buff *p, **pp = NULL;
+ struct udphdr *uh, *uh2;
+ unsigned int hlen, off;
+ int flush = 1;
+
+ if (NAPI_GRO_CB(skb)->udp_mark ||
+ (!skb->encapsulation && skb->ip_summed != CHECKSUM_COMPLETE))
+ goto out;
+
+ /* mark that this skb passed once through the udp gro layer */
+ NAPI_GRO_CB(skb)->udp_mark = 1;
+
+ off = skb_gro_offset(skb);
+ hlen = off + sizeof(*uh);
+ uh = skb_gro_header_fast(skb, off);
+ if (skb_gro_header_hard(skb, hlen)) {
+ uh = skb_gro_header_slow(skb, hlen, off);
+ if (unlikely(!uh))
+ goto out;
+ }
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(poffload, ohead, list) {
+ if (poffload->port != uh->dest || !poffload->callbacks.gro_receive)
+ continue;
+ break;
+ }
+
+ if (&poffload->list == ohead)
+ goto out_unlock;
+
+ flush = 0;
+
+ for (p = *head; p; p = p->next) {
+ if (!NAPI_GRO_CB(p)->same_flow)
+ continue;
+
+ uh2 = (struct udphdr *)(p->data + off);
+ if ((*(u32 *)&uh->source != *(u32 *)&uh2->source)) {
+ NAPI_GRO_CB(p)->same_flow = 0;
+ continue;
+ }
+ goto found;
+ }
+
+found:
+ skb_gro_pull(skb, sizeof(struct udphdr)); /* pull encapsulating udp header */
+ pp = poffload->callbacks.gro_receive(head, skb);
+
+out_unlock:
+ rcu_read_unlock();
+out:
+ NAPI_GRO_CB(skb)->flush |= flush;
+
+ return pp;
+}
+
+static int udp_gro_complete(struct sk_buff *skb, int nhoff)
+{
+ struct list_head *ohead = &udp_offload_base;
+ struct udp_offload *poffload;
+ __be16 newlen = htons(skb->len - nhoff);
+ struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
+ int err = -ENOSYS;
+
+ uh->len = newlen;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(poffload, ohead, list) {
+ if (poffload->port != uh->dest || !poffload->callbacks.gro_complete)
+ continue;
+ break;
+ }
+
+ if (&poffload->list != ohead)
+ err = poffload->callbacks.gro_complete(skb, nhoff + sizeof(struct udphdr));
+
+ rcu_read_unlock();
+ return err;
+}
+
static const struct net_offload udpv4_offload = {
.callbacks = {
.gso_send_check = udp4_ufo_send_check,
.gso_segment = udp4_ufo_fragment,
+ .gro_receive = udp_gro_receive,
+ .gro_complete = udp_gro_complete,
},
};
int __init udpv4_offload_init(void)
{
+ INIT_LIST_HEAD(&udp_offload_base);
return inet_add_offload(&udpv4_offload, IPPROTO_UDP);
}
--
1.7.1
^ permalink raw reply related
* [PATCH net-next V3 2/3] net: Export gro_find_by_type helpers
From: Or Gerlitz @ 2014-01-08 20:34 UTC (permalink / raw)
To: hkchu, edumazet, herbert; +Cc: netdev, davem, yanb, shlomop, Or Gerlitz
In-Reply-To: <1389213278-2200-1-git-send-email-ogerlitz@mellanox.com>
Export the gro_find_receive/complete_by_type helpers to they can be invoked
by the gro callbacks of encapsulation protocols such as vxlan.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
net/core/dev.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 11f7acf..a052e54 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3936,6 +3936,7 @@ struct packet_offload *gro_find_receive_by_type(__be16 type)
}
return NULL;
}
+EXPORT_SYMBOL(gro_find_receive_by_type);
struct packet_offload *gro_find_complete_by_type(__be16 type)
{
@@ -3949,6 +3950,7 @@ struct packet_offload *gro_find_complete_by_type(__be16 type)
}
return NULL;
}
+EXPORT_SYMBOL(gro_find_complete_by_type);
static gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
{
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next V3 1/3] net: Add GRO support for UDP encapsulating protocols
From: Or Gerlitz @ 2014-01-08 20:39 UTC (permalink / raw)
To: hkchu, edumazet, herbert; +Cc: netdev, davem, yanb, shlomop, Or Gerlitz
In-Reply-To: <1389213278-2200-2-git-send-email-ogerlitz@mellanox.com>
On 08/01/2014 22:34, Or Gerlitz wrote:
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -13,6 +13,16 @@
> #include <linux/skbuff.h>
> #include <net/udp.h>
> #include <net/protocol.h>
> +/*
> +struct udp_offload {
> + __be16 port;
> + struct offload_callbacks callbacks;
> + struct list_head list;
> +};
> +*/
sorry for this small mess, will clean it up
^ permalink raw reply
* Re: [PATCH net-next] net: xfrm6: silence sparse warning
From: Ben Hutchings @ 2014-01-08 20:46 UTC (permalink / raw)
To: David Miller; +Cc: ying.xue, steffen.klassert, dborkman, netdev
In-Reply-To: <20140107.224357.1577838150943921013.davem@davemloft.net>
On Tue, 2014-01-07 at 22:43 -0500, David Miller wrote:
> From: Ying Xue <ying.xue@windriver.com>
> Date: Wed, 8 Jan 2014 10:56:40 +0800
>
> > Fix below sparse warning:
> >
> > net/ipv6/xfrm6_state.c:66:26: error: cannot size expression
> ...
> > - memset(count, 0, sizeof(count));
> > + memset(count, 0, sizeof(int) * maxclass);
>
> I think the fix belongs in sparse, making it respect these two expressions
> as equivalent.
It looks like sparse just doesn't support sizeof(VLA), although this is
valid C.
(It makes the same complaint about some places in sfc where we've used
min_t() in array dimensions, as that makes them VLAs even though the
size can actually be determined at compile time.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v4 3/4] ARM: shmobile: r7s72100: Add clock for r7s72100-ether
From: Sergei Shtylyov @ 2014-01-08 21:03 UTC (permalink / raw)
To: Simon Horman, David S. Miller, netdev, linux-sh
Cc: linux-arm-kernel, Magnus Damm
In-Reply-To: <1389168152-9434-4-git-send-email-horms+renesas@verge.net.au>
Hello.
On 01/08/2014 11:02 AM, Simon Horman wrote:
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next 2/3] virtio-net: use per-receive queue page frag alloc for mergeable bufs
From: Rick Jones @ 2014-01-08 21:16 UTC (permalink / raw)
To: Eric Dumazet, Michael S. Tsirkin
Cc: Michael Dalton, netdev, lf-virt, Eric Dumazet, David S. Miller
In-Reply-To: <1389204587.26646.111.camel@edumazet-glaptop2.roam.corp.google.com>
On 01/08/2014 10:09 AM, Eric Dumazet wrote:
> In normal networking land, when a host A sends frames to host B,
> nothing prevents A to pause the traffic to B if B is dropping packets
> under stress.
>
> A physical NIC do not use a workqueue to refill its RX queue but uses
> the following strategy :
>
> 0) Pre filling of RX ring buffer with N frames. This can use GFP_KERNEL
> allocations with all needed (sleep/retry/shout) logic...
> 1) IRQ is handled.
> 2) Can we allocate a new buffer (GFP_ATOMIC) ?
> If yes, we accept the frame,
> and post the new buffer for the 'next frame'
> If no, we drop the frame and recycle the memory for next round.
and increment a suitably specific statistic so someone trying
to diagnose performance/other problems can know we dropped the frame.
rick jones
^ permalink raw reply
* Re: [PATCH] unix: show socket peer if no addr is given in /proc/net/unix
From: Sergei Shtylyov @ 2014-01-08 22:19 UTC (permalink / raw)
To: Masatake YAMATO, netdev
In-Reply-To: <1389158288-2855-1-git-send-email-yamato@redhat.com>
Hello.
On 01/08/2014 08:18 AM, Masatake YAMATO wrote:
> Path field of /proc/net/unix is empty if an address is not given
> to a socket. Typical way to create such socket is calling
> socketpair. The empty fields make it difficult to understand the
> communication between processes. e.g. lsof cannot resolve the role of
> file descriptors well.
> This patch fills the empty fields with unix_peer.
> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
> ---
> net/unix/af_unix.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 800ca61..1700133 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -2340,7 +2340,9 @@ static int unix_seq_show(struct seq_file *seq, void *v)
> else {
> struct sock *s = v;
> struct unix_sock *u = unix_sk(s);
> + struct sock *s_peer;
> unix_state_lock(s);
> + s_peer = unix_peer(s);
>
> seq_printf(seq, "%pK: %08X %08X %08X %04X %02X %5lu",
> s,
> @@ -2367,7 +2369,8 @@ static int unix_seq_show(struct seq_file *seq, void *v)
> }
> for ( ; i < len; i++)
> seq_putc(seq, u->addr->name->sun_path[i]);
> - }
> + } else if (s_peer)
> + seq_printf(seq, " #%pK", s_peer);
According to Documentation/CodingStyle, both arms of the *if* statement
should have {} if one has it.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net] xen-netback: fix vif tx queue race in xenvif_rx_interrupt
From: Zoltan Kiss @ 2014-01-08 21:18 UTC (permalink / raw)
To: Ma JieYue, netdev, xen-devel
Cc: Ma JieYue, Wang Yingbin, Fu Tienan, Wei Liu, Ian Campbell,
David Vrabel
In-Reply-To: <1389209061-29494-1-git-send-email-jieyue.majy@alibaba-inc.com>
Hi,
With Paul's recent flow control improvement I think this became invalid:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=ca2f09f2b2c6c25047cfc545d057c4edfcfe561c
Zoli
On 08/01/14 19:24, Ma JieYue wrote:
> From: Ma JieYue <jieyue.majy@alibaba-inc.com>
>
> There is a race when waking up or stopping xenvif tx queue, and it leads to
> unnecessary packet drop. The problem is that the rx ring still full when entering
> into xenvif_start_xmit. In fact, in xenvif_rx_interrupt, the netif_wake_queue
> may be called not just after the ring is not full any more, so the operation
> is not atomic. Here is part of the debug log when the race scenario happened:
>
> wake_queue: req_cons_peek 2679757 req_cons 2679586 req_prod 2679841
> stop_queue: req_cons_peek 2679837 req_cons 2679757 req_prod 2679841
> [tx_queue_stopped true]
> wake_queue: req_cons_peek 2679837 req_cons 2679757 req_prod 2679841
> [tx_queue_stopped false]
> drop packet: req_cons_peek 2679837 req_cons 2679757 req_prod 2679841
>
> The debug log was written, every time right after netif_wake_queue been called
> in xenvif_rx_interrupt, every time after netif_stop_queue been called in
> xenvif_start_xmit and every time packet drop happened in xenvif_start_xmit.
> As we can see, the second wake_queue appeared in the place it should not be, and
> we believed the ring had been checked before the stop_queue, but the actual
> wake_queue action didn't follow, and took place after the stop_queue, so that when
> entering into xenvif_start_xmit the ring was full but the queue was not stopped.
>
> The patch fixes the race by checking if tx queue stopped, before trying to
> wake it up in xenvif_rx_interrupt. It only wakes the queue when it is stopped,
> as well as it is not full and schedulable.
>
> Signed-off-by: Ma JieYue <jieyue.majy@alibaba-inc.com>
> Signed-off-by: Wang Yingbin <yingbin.wangyb@alibaba-inc.com>
> Signed-off-by: Fu Tienan <tienan.ftn@alibaba-inc.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: David Vrabel <david.vrabel@citrix.com>
> ---
> drivers/net/xen-netback/interface.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index fff8cdd..e099f62 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -105,7 +105,7 @@ static irqreturn_t xenvif_rx_interrupt(int irq, void *dev_id)
> {
> struct xenvif *vif = dev_id;
>
> - if (xenvif_rx_schedulable(vif))
> + if (netif_queue_stopped(vif->dev) && xenvif_rx_schedulable(vif))
> netif_wake_queue(vif->dev);
>
> return IRQ_HANDLED;
>
^ permalink raw reply
* Re: [PATCH net-next v3 8/9] xen-netback: Timeout packets in RX path
From: Zoltan Kiss @ 2014-01-08 21:34 UTC (permalink / raw)
To: ian.campbell, wei.liu2, xen-devel, netdev, linux-kernel,
jonathan.davies
Cc: Zoltan Kiss, Paul Durrant
In-Reply-To: <1389139818-24458-9-git-send-email-zoltan.kiss@citrix.com>
I just realized when answering Ma's mail that this doesn't cause the
desired effect after Paul's flow control improvement: starting the queue
doesn't drop the packets which cannot fit the ring. Which in fact might
be not good. We are adding the skb to vif->rx_queue even when
xenvif_rx_ring_slots_available(vif, min_slots_needed) said there is no
space for that. Or am I missing something? Paul?
Zoli
On 08/01/14 00:10, Zoltan Kiss wrote:
> A malicious or buggy guest can leave its queue filled indefinitely, in which
> case qdisc start to queue packets for that VIF. If those packets came from an
> another guest, it can block its slots and prevent shutdown. To avoid that, we
> make sure the queue is drained in every 10 seconds.
...
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 95fcd63..ce032f9 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -114,6 +114,16 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static void xenvif_wake_queue(unsigned long data)
> +{
> + struct xenvif *vif = (struct xenvif *)data;
> +
> + if (netif_queue_stopped(vif->dev)) {
> + netdev_err(vif->dev, "draining TX queue\n");
> + netif_wake_queue(vif->dev);
> + }
> +}
> +
> static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> struct xenvif *vif = netdev_priv(dev);
> @@ -143,8 +153,13 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
> * then turn off the queue to give the ring a chance to
> * drain.
> */
> - if (!xenvif_rx_ring_slots_available(vif, min_slots_needed))
> + if (!xenvif_rx_ring_slots_available(vif, min_slots_needed)) {
> + vif->wake_queue.function = xenvif_wake_queue;
> + vif->wake_queue.data = (unsigned long)vif;
> xenvif_stop_queue(vif);
> + mod_timer(&vif->wake_queue,
> + jiffies + rx_drain_timeout_jiffies);
> + }
>
> skb_queue_tail(&vif->rx_queue, skb);
> xenvif_kick_thread(vif);
^ permalink raw reply
* I have a very lucrative Business
From: Dr. Musa Hamed @ 2014-01-08 21:09 UTC (permalink / raw)
ATTN: Dear,
I am Dr. Musa Hamed Executive Director of the Bank of Africa
Plc B.O.A,Cotonou Benin Rep. I have a very lucrative Business proposal
worth of 21,500,000.00 USD.
An Iraqi named Hamadi Hashem a business man made a fixed deposit of
21,500,000.00 USD . Upon maturity several notices was sent to him,
even during the war,eleven years ago (2003) up till this date. Again
after the war another notification was sent and still no response came
from him. it has been found out that Hamadi Hashem and his family had
been killed during the war in bomb blast that hit their home at
Mukaradeeb where his personal oil well was. I am prepared to split the
funds with you 50%:50%.By placing you as the NEXT OF KIN to his
deposit.
Should you be interested in doing this deal with me, please send me
the following information:
(1) Your Name
(2) Resident Address
(3) Your Occupation
(4) Your Phone Number
(5) Date of Birth
(6) Resident Country
And I will prefer you to reach me privately and securely on my personal
email address: dr.musahamed30@yahoo.fr
Tel: +229-988-400-97
I will provide you with further information as soon as I hear
positively from you.
Regards,
Dr. Musa Hamed
^ permalink raw reply
* [PATCH ethtool] ethtool: Accept long feature names reported by -k option as input to -K option
From: Ben Hutchings @ 2014-01-08 21:52 UTC (permalink / raw)
To: Or Gerlitz, Bill Fink, netdev
Before the generic features API was introduced, the ethtool -K option
took short names for various features, e.g. 'gso' but the -k option
reported their state using longer names,
e.g. 'generic-segmentation-offload'.
All newer features have a single kernel-provided name so input
and output are consistent. But the old features still aren't, and
although their short names are documented it's not good to have
these exceptions.
Change the argument parsing code for -K so that the long names
reported by -k are also accepted.
Reported-by: Or Gerlitz <or.gerlitz@gmail.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
This turned out to be pretty easy to do as the argument processing is
all table-driven already. I'll push this if it works for you.
Ben.
ethtool.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index b06dfa3..4226d2e 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -2053,25 +2053,31 @@ static int do_sfeatures(struct cmd_context *ctx)
/* Generate cmdline_info for legacy flags and kernel-named
* features, and parse our arguments.
*/
- cmdline_features = calloc(ARRAY_SIZE(off_flag_def) + defs->n_features,
+ cmdline_features = calloc(2 * ARRAY_SIZE(off_flag_def) +
+ defs->n_features,
sizeof(cmdline_features[0]));
if (!cmdline_features) {
perror("Cannot parse arguments");
return 1;
}
- for (i = 0; i < ARRAY_SIZE(off_flag_def); i++)
+ for (i = 0; i < ARRAY_SIZE(off_flag_def); i++) {
flag_to_cmdline_info(off_flag_def[i].short_name,
off_flag_def[i].value,
&off_flags_wanted, &off_flags_mask,
- &cmdline_features[i]);
+ &cmdline_features[2 * i]);
+ flag_to_cmdline_info(off_flag_def[i].long_name,
+ off_flag_def[i].value,
+ &off_flags_wanted, &off_flags_mask,
+ &cmdline_features[2 * i] + 1);
+ }
for (i = 0; i < defs->n_features; i++)
flag_to_cmdline_info(
defs->def[i].name, FEATURE_FIELD_FLAG(i),
&FEATURE_WORD(efeatures->features, i, requested),
&FEATURE_WORD(efeatures->features, i, valid),
- &cmdline_features[ARRAY_SIZE(off_flag_def) + i]);
+ &cmdline_features[2 * ARRAY_SIZE(off_flag_def) + i]);
parse_generic_cmdline(ctx, &any_changed, cmdline_features,
- ARRAY_SIZE(off_flag_def) + defs->n_features);
+ 2 * ARRAY_SIZE(off_flag_def) + defs->n_features);
free(cmdline_features);
if (!any_changed) {
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [PATCH net-next v2 1/4] net: allow > 0 order atomic page alloc in skb_page_frag_refill
From: Debabrata Banerjee @ 2014-01-08 21:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael Dalton, Michael S. Tsirkin, netdev@vger.kernel.org,
jbaron, virtualization, Eric Dumazet, Joshua Hunt,
David S. Miller
In-Reply-To: <1389210371.31367.8.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, Jan 8, 2014 at 2:46 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2014-01-08 at 21:18 +0200, Michael S. Tsirkin wrote:
>> On Wed, Jan 08, 2014 at 10:26:03AM -0800, Eric Dumazet wrote:
>> > On Wed, 2014-01-08 at 20:08 +0200, Michael S. Tsirkin wrote:
>> >
>> > > Eric said we also need a patch to add __GFP_NORETRY, right?
>> > > Probably before this one in series.
>> >
>> > Nope, this __GFP_NORETRY has nothing to do with this.
>> >
>> > I am not yet convinced we want it.
>> >
>> > This needs mm guys advice, as its a tradeoff for mm layer more than
>> > networking...
>>
>> Well maybe Cc linux-mm then?
>
> Well, I do not care of people mlocking the memory and complaining that
> compaction does not work.
>
> If these people care, they should contact mm guys, eventually.
>
> Really this is an issue that has nothing to do with this patch set.
>
Actually I have more data on this:
1. __GFP_NORETRY really does help and should go into stable tree.
2. You may want to consider GFP_NOKSWAPD, because even in the
GFP_ATOMIC case you are waking up kswapd to do reclaims on a
continuous basis even when you don't enter direct reclaim.
3. mlocking memory had very little to do with it, that was a
red-herring. I tested out the problem scenario with no mlocks. You
simply need memory pressure from page_cache, and mm ends up constantly
reclaiming and trying to keep another 1-2GB free on our systems (8GB
phys ~4GB left for kernel, ~3GB optimally used for page_cache).
4. I think perhaps using a kmem_cache allocation for this buffer is
the right way to make this work. I am experimenting with a patch to do
this.
-Debabrata
-Debabrata
^ permalink raw reply
* Re: [PATCH net-next V3 1/3] net: Add GRO support for UDP encapsulating protocols
From: Tom Herbert @ 2014-01-08 21:58 UTC (permalink / raw)
To: Or Gerlitz
Cc: Jerry Chu, Eric Dumazet, Herbert Xu, Linux Netdev List,
David Miller, Yan Burman, Shlomo Pongratz
In-Reply-To: <1389213278-2200-2-git-send-email-ogerlitz@mellanox.com>
On Wed, Jan 8, 2014 at 12:34 PM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> Add GRO handlers for protocols that do UDP encapsulation, with the intent of
> being able to coalesce packets which encapsulate packets belonging to
> the same TCP session.
>
> For GRO purposes, the destination UDP port takes the role of the ether type
> field in the ethernet header or the next protocol in the IP header.
>
> The UDP GRO handler will only attempt to coalesce packets whose destination
> port is registered to have gro handler.
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
> include/linux/netdevice.h | 10 +++-
> include/net/protocol.h | 3 +
> net/core/dev.c | 1 +
> net/ipv4/udp_offload.c | 129 +++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 142 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index a2a70cc..360551a 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1652,7 +1652,9 @@ struct napi_gro_cb {
> unsigned long age;
>
> /* Used in ipv6_gro_receive() */
> - int proto;
> + u16 proto;
> +
> + u16 udp_mark;
>
> /* used to support CHECKSUM_COMPLETE for tunneling protocols */
> __wsum csum;
> @@ -1691,6 +1693,12 @@ struct packet_offload {
> struct list_head list;
> };
>
> +struct udp_offload {
> + __be16 port;
> + struct offload_callbacks callbacks;
> + struct list_head list;
> +};
> +
> /* often modified stats are per cpu, other are shared (netdev->stats) */
> struct pcpu_sw_netstats {
> u64 rx_packets;
> diff --git a/include/net/protocol.h b/include/net/protocol.h
> index fbf7676..fe9af94 100644
> --- a/include/net/protocol.h
> +++ b/include/net/protocol.h
> @@ -103,6 +103,9 @@ int inet_del_offload(const struct net_offload *prot, unsigned char num);
> void inet_register_protosw(struct inet_protosw *p);
> void inet_unregister_protosw(struct inet_protosw *p);
>
> +void udp_add_offload(struct udp_offload *prot);
> +void udp_del_offload(struct udp_offload *prot);
> +
> #if IS_ENABLED(CONFIG_IPV6)
> int inet6_add_protocol(const struct inet6_protocol *prot, unsigned char num);
> int inet6_del_protocol(const struct inet6_protocol *prot, unsigned char num);
> diff --git a/net/core/dev.c b/net/core/dev.c
> index ce01847..11f7acf 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3858,6 +3858,7 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
> NAPI_GRO_CB(skb)->same_flow = 0;
> NAPI_GRO_CB(skb)->flush = 0;
> NAPI_GRO_CB(skb)->free = 0;
> + NAPI_GRO_CB(skb)->udp_mark = 0;
>
> pp = ptype->callbacks.gro_receive(&napi->gro_list, skb);
> break;
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 79c62bd..2846ade 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -13,6 +13,16 @@
> #include <linux/skbuff.h>
> #include <net/udp.h>
> #include <net/protocol.h>
> +/*
> +struct udp_offload {
> + __be16 port;
> + struct offload_callbacks callbacks;
> + struct list_head list;
> +};
> +*/
> +
> +static DEFINE_SPINLOCK(udp_offload_lock);
> +static struct list_head udp_offload_base __read_mostly;
>
> static int udp4_ufo_send_check(struct sk_buff *skb)
> {
> @@ -89,14 +99,133 @@ out:
> return segs;
> }
>
> +void udp_add_offload(struct udp_offload *uo)
> +{
> + struct list_head *head = &udp_offload_base;
> +
> + spin_lock(&udp_offload_lock);
> + list_add_rcu(&uo->list, head);
> + spin_unlock(&udp_offload_lock);
> +}
> +EXPORT_SYMBOL(udp_add_offload);
> +
> +void udp_del_offload(struct udp_offload *uo)
> +{
> + struct list_head *head = &udp_offload_base;
> + struct udp_offload *uo1;
> +
> + spin_lock(&udp_offload_lock);
> + list_for_each_entry(uo1, head, list) {
> + if (uo == uo1) {
> + list_del_rcu(&uo->list);
> + goto out;
> + }
> + }
> +
> + pr_warn("udp_remove_offload: %p not found port %d\n", uo, htons(uo->port));
> +out:
> + spin_unlock(&udp_offload_lock);
> +
> + synchronize_net();
> +}
> +EXPORT_SYMBOL(udp_del_offload);
> +
> +static struct sk_buff **udp_gro_receive(struct sk_buff **head, struct sk_buff *skb)
> +{
> + struct list_head *ohead = &udp_offload_base;
> + struct udp_offload *poffload;
> + struct sk_buff *p, **pp = NULL;
> + struct udphdr *uh, *uh2;
> + unsigned int hlen, off;
> + int flush = 1;
> +
> + if (NAPI_GRO_CB(skb)->udp_mark ||
> + (!skb->encapsulation && skb->ip_summed != CHECKSUM_COMPLETE))
> + goto out;
> +
> + /* mark that this skb passed once through the udp gro layer */
> + NAPI_GRO_CB(skb)->udp_mark = 1;
> +
> + off = skb_gro_offset(skb);
> + hlen = off + sizeof(*uh);
> + uh = skb_gro_header_fast(skb, off);
> + if (skb_gro_header_hard(skb, hlen)) {
> + uh = skb_gro_header_slow(skb, hlen, off);
> + if (unlikely(!uh))
> + goto out;
> + }
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(poffload, ohead, list) {
> + if (poffload->port != uh->dest || !poffload->callbacks.gro_receive)
Is gro_receive == NULL ever valid? Maybe we can assert on registration
instead of checking on every packet.
Maybe make this poffload->port == uh->dest and goto "flush = 0".
Check below that list end was reached becomes unnecessary.
> + continue;
> + break;
> + }
> +
> + if (&poffload->list == ohead)
> + goto out_unlock;
> +
> + flush = 0;
> +
> + for (p = *head; p; p = p->next) {
> + if (!NAPI_GRO_CB(p)->same_flow)
> + continue;
> +
> + uh2 = (struct udphdr *)(p->data + off);
> + if ((*(u32 *)&uh->source != *(u32 *)&uh2->source)) {
> + NAPI_GRO_CB(p)->same_flow = 0;
> + continue;
> + }
> + goto found;
> + }
> +
> +found:
> + skb_gro_pull(skb, sizeof(struct udphdr)); /* pull encapsulating udp header */
> + pp = poffload->callbacks.gro_receive(head, skb);
> +
> +out_unlock:
> + rcu_read_unlock();
> +out:
> + NAPI_GRO_CB(skb)->flush |= flush;
> +
> + return pp;
> +}
> +
> +static int udp_gro_complete(struct sk_buff *skb, int nhoff)
> +{
> + struct list_head *ohead = &udp_offload_base;
> + struct udp_offload *poffload;
> + __be16 newlen = htons(skb->len - nhoff);
> + struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
> + int err = -ENOSYS;
> +
> + uh->len = newlen;
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(poffload, ohead, list) {
> + if (poffload->port != uh->dest || !poffload->callbacks.gro_complete)
> + continue;
> + break;
> + }
> +
> + if (&poffload->list != ohead)
> + err = poffload->callbacks.gro_complete(skb, nhoff + sizeof(struct udphdr));
> +
> + rcu_read_unlock();
> + return err;
> +}
> +
> static const struct net_offload udpv4_offload = {
> .callbacks = {
> .gso_send_check = udp4_ufo_send_check,
> .gso_segment = udp4_ufo_fragment,
> + .gro_receive = udp_gro_receive,
> + .gro_complete = udp_gro_complete,
> },
> };
>
> int __init udpv4_offload_init(void)
> {
> + INIT_LIST_HEAD(&udp_offload_base);
> return inet_add_offload(&udpv4_offload, IPPROTO_UDP);
> }
> --
> 1.7.1
>
> --
> 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: [PATCH ethtool] ethtool: Accept long feature names reported by -k option as input to -K option
From: Allan, Bruce W @ 2014-01-08 22:00 UTC (permalink / raw)
To: Ben Hutchings, Or Gerlitz, Bill Fink, netdev@vger.kernel.org
In-Reply-To: <1389217931.1644.44.camel@bwh-desktop.uk.level5networks.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Ben Hutchings
> Sent: Wednesday, January 08, 2014 1:52 PM
> To: Or Gerlitz; Bill Fink; netdev@vger.kernel.org
> Subject: [PATCH ethtool] ethtool: Accept long feature names reported by -k
> option as input to -K option
>
> Before the generic features API was introduced, the ethtool -K option
> took short names for various features, e.g. 'gso' but the -k option
> reported their state using longer names,
> e.g. 'generic-segmentation-offload'.
>
> All newer features have a single kernel-provided name so input
> and output are consistent. But the old features still aren't, and
> although their short names are documented it's not good to have
> these exceptions.
>
> Change the argument parsing code for -K so that the long names
> reported by -k are also accepted.
>
> Reported-by: Or Gerlitz <or.gerlitz@gmail.com>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> This turned out to be pretty easy to do as the argument processing is
> all table-driven already. I'll push this if it works for you.
>
> Ben.
>
> ethtool.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
Will there be an update to the man page, too?
^ permalink raw reply
* Re: [PATCH net-next v2 1/4] net: allow > 0 order atomic page alloc in skb_page_frag_refill
From: Eric Dumazet @ 2014-01-08 22:01 UTC (permalink / raw)
To: Debabrata Banerjee
Cc: Michael Dalton, Michael S. Tsirkin, netdev@vger.kernel.org,
jbaron, virtualization, Eric Dumazet, Joshua Hunt,
David S. Miller
In-Reply-To: <CAATkVEypFGfXuiBwFacOMjAWyYmLXHiihdpQfJp+CRFEZJagyg@mail.gmail.com>
On Wed, 2014-01-08 at 16:54 -0500, Debabrata Banerjee wrote:
> Actually I have more data on this:
>
Could you please stop polluting this thread ?
> 1. __GFP_NORETRY really does help and should go into stable tree.
>
Not at all. You are free to patch your kernel if you want.
It helps you workload, and breaks all others.
If compaction is never triggered, we'll never be able to get high order
pages, and performance goes back to what we had 2 years ago.
That discussion does not belong to this thread, again.
> 2. You may want to consider GFP_NOKSWAPD, because even in the
> GFP_ATOMIC case you are waking up kswapd to do reclaims on a
> continuous basis even when you don't enter direct reclaim.
>
> 3. mlocking memory had very little to do with it, that was a
> red-herring. I tested out the problem scenario with no mlocks. You
> simply need memory pressure from page_cache, and mm ends up constantly
> reclaiming and trying to keep another 1-2GB free on our systems (8GB
> phys ~4GB left for kernel, ~3GB optimally used for page_cache).
>
> 4. I think perhaps using a kmem_cache allocation for this buffer is
> the right way to make this work. I am experimenting with a patch to do
> this.
Seriously... I think you missed whole point of having frag allocation on
pages, not kmem_cache.
^ permalink raw reply
* Re: [PATCH net-next V3 3/3] net: Add GRO support for vxlan traffic
From: Eric Dumazet @ 2014-01-08 22:09 UTC (permalink / raw)
To: Or Gerlitz; +Cc: hkchu, edumazet, herbert, netdev, davem, yanb, shlomop
In-Reply-To: <1389213278-2200-4-git-send-email-ogerlitz@mellanox.com>
On Wed, 2014-01-08 at 22:34 +0200, Or Gerlitz wrote:
> +
> +static int vxlan_gro_complete(struct sk_buff *skb, int nhoff)
> +{
> + struct ethhdr *eh;
> + struct packet_offload *ptype;
> + __be16 type;
> + /* 22 = 8 bytes for the vlxan header + 14 bytes for the inner eth header */
> + int vxlan_len = 22;
I am pretty sure this can use existing macros or sizeof(...)
^ permalink raw reply
* Re: [PATCH net-next V3 3/3] net: Add GRO support for vxlan traffic
From: Eric Dumazet @ 2014-01-08 22:11 UTC (permalink / raw)
To: Or Gerlitz; +Cc: hkchu, edumazet, herbert, netdev, davem, yanb, shlomop
In-Reply-To: <1389213278-2200-4-git-send-email-ogerlitz@mellanox.com>
On Wed, 2014-01-08 at 22:34 +0200, Or Gerlitz wrote:
> +
> /* Notify netdevs that UDP port started listening */
> -static void vxlan_notify_add_rx_port(struct sock *sk)
> +static void vxlan_notify_add_rx_port(struct vxlan_sock *vs)
> {
> struct net_device *dev;
> + struct sock *sk = vs->sock->sk;
> struct net *net = sock_net(sk);
> sa_family_t sa_family = sk->sk_family;
> __be16 port = inet_sk(sk)->inet_sport;
> @@ -569,12 +671,16 @@ static void vxlan_notify_add_rx_port(struct sock *sk)
> port);
> }
> rcu_read_unlock();
> +
> + if (sa_family == AF_INET)
> + call_rcu(&vs->rcu, vxlan_add_udp_offload);
Why waiting RCU grace period here ?
> }
>
> /* Notify netdevs that UDP port is no more listening */
> -static void vxlan_notify_del_rx_port(struct sock *sk)
> +static void vxlan_notify_del_rx_port(struct vxlan_sock *vs)
> {
> struct net_device *dev;
> + struct sock *sk = vs->sock->sk;
> struct net *net = sock_net(sk);
> sa_family_t sa_family = sk->sk_family;
> __be16 port = inet_sk(sk)->inet_sport;
> @@ -586,6 +692,9 @@ static void vxlan_notify_del_rx_port(struct sock *sk)
> port);
> }
> rcu_read_unlock();
> +
> + if (sa_family == AF_INET)
> + call_rcu(&vs->rcu, vxlan_del_udp_offload);
> }
This looks buggy.
You need to :
1) remove the offload structure from list
2) Then wait rcu grace period, and finally free the memory
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: add skb_checksum_setup
From: Eric Dumazet @ 2014-01-08 22:43 UTC (permalink / raw)
To: Paul Durrant
Cc: netdev, xen-devel, David Miller, Eric Dumazet, Veaceslav Falico,
Alexander Duyck, Nicolas Dichtel
In-Reply-To: <1389189511-14568-2-git-send-email-paul.durrant@citrix.com>
On Wed, 2014-01-08 at 13:58 +0000, Paul Durrant wrote:
> This patch adds a function to set up the partial checksum offset for IP
> packets (and optionally re-calculate the pseudo-header checksum) into the
> core network code.
> The implementation was previously private and duplicated between xen-netback
> and xen-netfront, however it is not xen-specific and is potentially useful
> to any network driver.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: David Miller <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Veaceslav Falico <vfalico@redhat.com>
> Cc: Alexander Duyck <alexander.h.duyck@intel.com>
> Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> include/linux/netdevice.h | 1 +
> net/core/dev.c | 271 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 272 insertions(+)
Is there any reason to put this in net/core/dev.c instead of
net/core/skbuff.c ?
Also, no inline should be used in a .c file
( skb_maybe_pull_tail )
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] tcp: metrics: Add source-address to tcp-metrics
From: Christoph Paasch @ 2014-01-08 22:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David Miller, Yuchung Cheng, Julian Anastasov
In-Reply-To: <1389203751.26646.100.camel@edumazet-glaptop2.roam.corp.google.com>
Hello Eric,
On 08/01/14 - 09:55:51, Eric Dumazet wrote:
> On Wed, 2014-01-08 at 16:05 +0100, Christoph Paasch wrote:
> > We add the source-address to the tcp-metrics, so that different metrics
> > will be used per source/destination-pair. We use the destination-hash to
> > store the metric inside the hash-table. That way, deleting and dumping
> > via "ip tcp_metrics" is easy.
>
> Note that this has the following problem :
>
> Some applications use a set of source IP addresses to overcome the 64K
> port limitation.
Ok, did not know about that.
> tcp_metrics uses a hard-coded TCP_METRICS_RECLAIM_DEPTH value of 5,
> meaning that cache wont be able to store more than 5 source IP addresses
> (reaching one particular remote IP).
Maybe we could do something like the below (yet untested). That way we allow
up to 32 entries with the same destination but different source and still
only 5 with different destinations.
I guess 32 * 64K connections is enough. :)
We could also make TCP_METRICS_RECLAIM_DEPTH(_DST) a tunable.
diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
index 699a42faab9c..0418ac318e7d 100644
--- a/net/ipv4/tcp_metrics.c
+++ b/net/ipv4/tcp_metrics.c
@@ -181,13 +181,18 @@ static void tcpm_check_stamp(struct tcp_metrics_block *tm, struct dst_entry *dst
}
#define TCP_METRICS_RECLAIM_DEPTH 5
+#define TCP_METRICS_RECLAIM_DEPTH_DST 32
#define TCP_METRICS_RECLAIM_PTR (struct tcp_metrics_block *) 0x1UL
-static struct tcp_metrics_block *tcp_get_encode(struct tcp_metrics_block *tm, int depth)
+static struct tcp_metrics_block *tcp_get_encode(struct tcp_metrics_block *tm,
+ int depth_general,
+ int depth_dst)
{
if (tm)
return tm;
- if (depth > TCP_METRICS_RECLAIM_DEPTH)
+ if (depth_general > TCP_METRICS_RECLAIM_DEPTH)
+ return TCP_METRICS_RECLAIM_PTR;
+ if (depth_dst > TCP_METRICS_RECLAIM_DEPTH_DST)
return TCP_METRICS_RECLAIM_PTR;
return NULL;
}
@@ -197,16 +202,19 @@ static struct tcp_metrics_block *__tcp_get_metrics(const struct inetpeer_addr *s
struct net *net, unsigned int hash)
{
struct tcp_metrics_block *tm;
- int depth = 0;
+ int depth_dst = 0, depth_general = 0;
for (tm = rcu_dereference(net->ipv4.tcp_metrics_hash[hash].chain); tm;
tm = rcu_dereference(tm->tcpm_next)) {
if (addr_same(&tm->tcpm_saddr, saddr) &&
addr_same(&tm->tcpm_daddr, daddr))
break;
- depth++;
+ if (addr_same(&tm->tcpm_daddr, daddr))
+ depth_dst++;
+ else
+ depth_general++;
}
- return tcp_get_encode(tm, depth);
+ return tcp_get_encode(tm, depth_general, depth_dst);
}
static struct tcp_metrics_block *__tcp_get_metrics_req(struct request_sock *req,
^ permalink raw reply related
* Re: Bug: alx: Atheros AR8131/AR8151/AR8152/AR8161 Ethernet driver
From: Sam @ 2014-01-08 22:53 UTC (permalink / raw)
To: netdev
In-Reply-To: <CACtZaF+aamW_0P2O1zSGLWHmichAZKb96pC4GCCVZZXJsh8Y7g@mail.gmail.com>
Kinley Dorji <kinleyd <at> gmail.com> writes:
>
> <at> Johannes Berg: > don't really care much for the
> > stats in the system I'm using this device on - and based on the driver
> > I'm not sure I'd use the chip for 'serious' work anyway :)
>
> OTOH, conky users love having the stats up, even if they aren't precise. :)
>
> There's one other point:
>
> Before the mainlining of the alx drivers, the default settings for
> Wake-on used to be d, whereas now it seems to be pg. This startled me
> a couple of times with my computer turning on unexpectedly, having
> been used to the previous defaults. Just FYI.
>
> Other than that, I would like thank you all very much for your quick
> responses and I look forward to having the stats code restored to the
> alx drivers.
>
> With best regards,
>
> Kinley
>
Hi guys,
I am experiencing this bug on a 3.11 kernel.
Can you tell me if the fix has been released upstream? in which kernel version?
Thanks
Regards
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] tcp: metrics: Add source-address to tcp-metrics
From: Eric Dumazet @ 2014-01-08 23:13 UTC (permalink / raw)
To: Christoph Paasch; +Cc: netdev, David Miller, Yuchung Cheng, Julian Anastasov
In-Reply-To: <20140108224344.GE4700@cpaasch-mac>
On Wed, 2014-01-08 at 23:43 +0100, Christoph Paasch wrote:
> Hello Eric,
>
> On 08/01/14 - 09:55:51, Eric Dumazet wrote:
> > On Wed, 2014-01-08 at 16:05 +0100, Christoph Paasch wrote:
> > > We add the source-address to the tcp-metrics, so that different metrics
> > > will be used per source/destination-pair. We use the destination-hash to
> > > store the metric inside the hash-table. That way, deleting and dumping
> > > via "ip tcp_metrics" is easy.
> >
> > Note that this has the following problem :
> >
> > Some applications use a set of source IP addresses to overcome the 64K
> > port limitation.
>
> Ok, did not know about that.
>
> > tcp_metrics uses a hard-coded TCP_METRICS_RECLAIM_DEPTH value of 5,
> > meaning that cache wont be able to store more than 5 source IP addresses
> > (reaching one particular remote IP).
>
> Maybe we could do something like the below (yet untested). That way we allow
> up to 32 entries with the same destination but different source and still
> only 5 with different destinations.
>
> I guess 32 * 64K connections is enough. :)
> We could also make TCP_METRICS_RECLAIM_DEPTH(_DST) a tunable.
Well, not sure if this is a problem anyway, and if we want extra
complexity for this rare use case, considering tcp metrics for
high number of flows sharing a common path is unlikely to be useful
(with exception of Fast Open, but again it must be rare)
^ permalink raw reply
* [PATCH v4 0/2] ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes
From: Thomas Haller @ 2014-01-09 0:30 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Jiri Pirko, netdev, stephen, dcbw, Thomas Haller
In-Reply-To: <20140108200019.GK9007@order.stressinduktion.org>
v1 -> v2: add a second commit, handling NOPREFIXROUTE in ip6_del_addr.
v2 -> v3: reword commit messages, code comments and some refactoring.
v3 -> v4: refactor, rename variables, add enum
Thomas Haller (2):
ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of
IP6 routes
ipv6 addrconf: don't cleanup prefix route for IFA_F_NOPREFIXROUTE
include/uapi/linux/if_addr.h | 1 +
net/ipv6/addrconf.c | 203 ++++++++++++++++++++++++++-----------------
2 files changed, 123 insertions(+), 81 deletions(-)
--
1.8.4.2
^ 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