* [PATCH net-next v7 2/8] vxlan: Restructure vxlan receive.
From: Pravin B Shelar @ 2013-08-19 18:22 UTC (permalink / raw)
To: netdev, davem; +Cc: stephen, Pravin B Shelar
Use iptunnel_pull_header() for better code sharing.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
v5-v6:
split from second patch from v5 series.
---
drivers/net/vxlan.c | 22 +++++++---------------
1 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index b784ee6..1afb979 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -57,6 +57,7 @@
#define VXLAN_VID_MASK (VXLAN_N_VID - 1)
/* IP header + UDP + VXLAN + Ethernet header */
#define VXLAN_HEADROOM (20 + 8 + 8 + 14)
+#define VXLAN_HLEN (sizeof(struct udphdr) + sizeof(struct vxlanhdr))
#define VXLAN_FLAGS 0x08000000 /* struct vxlanhdr.vx_flags required value. */
@@ -868,15 +869,12 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
__u32 vni;
int err;
- /* pop off outer UDP header */
- __skb_pull(skb, sizeof(struct udphdr));
-
/* Need Vxlan and inner Ethernet header to be present */
- if (!pskb_may_pull(skb, sizeof(struct vxlanhdr)))
+ if (!pskb_may_pull(skb, VXLAN_HLEN))
goto error;
- /* Drop packets with reserved bits set */
- vxh = (struct vxlanhdr *) skb->data;
+ /* Return packets with reserved bits set */
+ vxh = (struct vxlanhdr *)(udp_hdr(skb) + 1);
if (vxh->vx_flags != htonl(VXLAN_FLAGS) ||
(vxh->vx_vni & htonl(0xff))) {
netdev_dbg(skb->dev, "invalid vxlan flags=%#x vni=%#x\n",
@@ -884,8 +882,6 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
goto error;
}
- __skb_pull(skb, sizeof(struct vxlanhdr));
-
/* Is this VNI defined? */
vni = ntohl(vxh->vx_vni) >> 8;
port = inet_sk(sk)->inet_sport;
@@ -896,7 +892,7 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
goto drop;
}
- if (!pskb_may_pull(skb, ETH_HLEN)) {
+ if (iptunnel_pull_header(skb, VXLAN_HLEN, htons(ETH_P_TEB))) {
vxlan->dev->stats.rx_length_errors++;
vxlan->dev->stats.rx_errors++;
goto drop;
@@ -904,8 +900,6 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
skb_reset_mac_header(skb);
- /* Re-examine inner Ethernet packet */
- oip = ip_hdr(skb);
skb->protocol = eth_type_trans(skb, vxlan->dev);
/* Ignore packet loops (and multicast echo) */
@@ -913,11 +907,12 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
vxlan->dev->dev_addr) == 0)
goto drop;
+ /* Re-examine inner Ethernet packet */
+ oip = ip_hdr(skb);
if ((vxlan->flags & VXLAN_F_LEARN) &&
vxlan_snoop(skb->dev, oip->saddr, eth_hdr(skb)->h_source))
goto drop;
- __skb_tunnel_rx(skb, vxlan->dev);
skb_reset_network_header(skb);
/* If the NIC driver gave us an encapsulated packet with
@@ -953,9 +948,6 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
return 0;
error:
- /* Put UDP header back */
- __skb_push(skb, sizeof(struct udphdr));
-
return 1;
drop:
/* Consume bad packet */
--
1.7.1
^ permalink raw reply related
* [PATCH net-next v7 1/8] vxlan: Restructure vxlan socket apis.
From: Pravin B Shelar @ 2013-08-19 18:22 UTC (permalink / raw)
To: netdev, davem; +Cc: stephen, Pravin B Shelar
Restructure vxlan-socket management APIs so that it can be
shared between vxlan and ovs modules.
This patch does not change any functionality.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
v6-v7:
- get rid of zero refcnt vs from hashtable.
---
drivers/net/vxlan.c | 92 ++++++++++++++++++++++++++++----------------------
1 files changed, 51 insertions(+), 41 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 570ad7a..b784ee6 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -188,7 +188,7 @@ static inline struct vxlan_rdst *first_remote_rtnl(struct vxlan_fdb *fdb)
}
/* Find VXLAN socket based on network namespace and UDP port */
-static struct vxlan_sock *vxlan_find_port(struct net *net, __be16 port)
+static struct vxlan_sock *vxlan_find_sock(struct net *net, __be16 port)
{
struct vxlan_sock *vs;
@@ -205,7 +205,7 @@ static struct vxlan_dev *vxlan_find_vni(struct net *net, u32 id, __be16 port)
struct vxlan_sock *vs;
struct vxlan_dev *vxlan;
- vs = vxlan_find_port(net, port);
+ vs = vxlan_find_sock(net, port);
if (!vs)
return NULL;
@@ -1365,25 +1365,31 @@ static void vxlan_cleanup(unsigned long arg)
mod_timer(&vxlan->age_timer, next_timer);
}
+static void vxlan_vs_add_dev(struct vxlan_sock *vs, struct vxlan_dev *vxlan)
+{
+ __u32 vni = vxlan->default_dst.remote_vni;
+
+ vxlan->vn_sock = vs;
+ hlist_add_head_rcu(&vxlan->hlist, vni_head(vs, vni));
+}
+
/* Setup stats when device is created */
static int vxlan_init(struct net_device *dev)
{
struct vxlan_dev *vxlan = netdev_priv(dev);
struct vxlan_net *vn = net_generic(dev_net(dev), vxlan_net_id);
struct vxlan_sock *vs;
- __u32 vni = vxlan->default_dst.remote_vni;
dev->tstats = alloc_percpu(struct pcpu_tstats);
if (!dev->tstats)
return -ENOMEM;
spin_lock(&vn->sock_lock);
- vs = vxlan_find_port(dev_net(dev), vxlan->dst_port);
+ vs = vxlan_find_sock(dev_net(dev), vxlan->dst_port);
if (vs) {
/* If we have a socket with same port already, reuse it */
atomic_inc(&vs->refcnt);
- vxlan->vn_sock = vs;
- hlist_add_head_rcu(&vxlan->hlist, vni_head(vs, vni));
+ vxlan_vs_add_dev(vs, vxlan);
} else {
/* otherwise make new socket outside of RTNL */
dev_hold(dev);
@@ -1633,6 +1639,7 @@ static void vxlan_del_work(struct work_struct *work)
static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port)
{
+ struct vxlan_net *vn = net_generic(net, vxlan_net_id);
struct vxlan_sock *vs;
struct sock *sk;
struct sockaddr_in vxlan_addr = {
@@ -1644,8 +1651,10 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port)
unsigned int h;
vs = kmalloc(sizeof(*vs), GFP_KERNEL);
- if (!vs)
+ if (!vs) {
+ pr_debug("memory alocation failure\n");
return ERR_PTR(-ENOMEM);
+ }
for (h = 0; h < VNI_HASH_SIZE; ++h)
INIT_HLIST_HEAD(&vs->vni_list[h]);
@@ -1673,57 +1682,57 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port)
kfree(vs);
return ERR_PTR(rc);
}
+ atomic_set(&vs->refcnt, 1);
/* Disable multicast loopback */
inet_sk(sk)->mc_loop = 0;
+ spin_lock(&vn->sock_lock);
+ hlist_add_head_rcu(&vs->hlist, vs_head(net, port));
+ spin_unlock(&vn->sock_lock);
/* Mark socket as an encapsulation socket. */
udp_sk(sk)->encap_type = 1;
udp_sk(sk)->encap_rcv = vxlan_udp_encap_recv;
udp_encap_enable();
- atomic_set(&vs->refcnt, 1);
+ return vs;
+}
+
+static struct vxlan_sock *vxlan_sock_add(struct net *net, __be16 port)
+{
+ struct vxlan_net *vn = net_generic(net, vxlan_net_id);
+ struct vxlan_sock *vs;
+
+ vs = vxlan_socket_create(net, port);
+ if (!IS_ERR(vs))
+ return vs;
+ spin_lock(&vn->sock_lock);
+ vs = vxlan_find_sock(net, port);
+ if (vs)
+ atomic_inc(&vs->refcnt);
+ else
+ vs = ERR_PTR(-EINVAL);
+
+ spin_unlock(&vn->sock_lock);
return vs;
}
/* Scheduled at device creation to bind to a socket */
static void vxlan_sock_work(struct work_struct *work)
{
- struct vxlan_dev *vxlan
- = container_of(work, struct vxlan_dev, sock_work);
- struct net_device *dev = vxlan->dev;
- struct net *net = dev_net(dev);
- __u32 vni = vxlan->default_dst.remote_vni;
- __be16 port = vxlan->dst_port;
+ struct vxlan_dev *vxlan = container_of(work, struct vxlan_dev, sock_work);
+ struct net *net = dev_net(vxlan->dev);
struct vxlan_net *vn = net_generic(net, vxlan_net_id);
- struct vxlan_sock *nvs, *ovs;
-
- nvs = vxlan_socket_create(net, port);
- if (IS_ERR(nvs)) {
- netdev_err(vxlan->dev, "Can not create UDP socket, %ld\n",
- PTR_ERR(nvs));
- goto out;
- }
+ __be16 port = vxlan->dst_port;
+ struct vxlan_sock *nvs;
+ nvs = vxlan_sock_add(net, port);
spin_lock(&vn->sock_lock);
- /* Look again to see if can reuse socket */
- ovs = vxlan_find_port(net, port);
- if (ovs) {
- atomic_inc(&ovs->refcnt);
- vxlan->vn_sock = ovs;
- hlist_add_head_rcu(&vxlan->hlist, vni_head(ovs, vni));
- spin_unlock(&vn->sock_lock);
-
- sk_release_kernel(nvs->sock->sk);
- kfree(nvs);
- } else {
- vxlan->vn_sock = nvs;
- hlist_add_head_rcu(&nvs->hlist, vs_head(net, port));
- hlist_add_head_rcu(&vxlan->hlist, vni_head(nvs, vni));
- spin_unlock(&vn->sock_lock);
- }
-out:
- dev_put(dev);
+ if (!IS_ERR(nvs))
+ vxlan_vs_add_dev(nvs, vxlan);
+ spin_unlock(&vn->sock_lock);
+
+ dev_put(vxlan->dev);
}
static int vxlan_newlink(struct net *net, struct net_device *dev,
@@ -1838,7 +1847,8 @@ static void vxlan_dellink(struct net_device *dev, struct list_head *head)
struct vxlan_dev *vxlan = netdev_priv(dev);
spin_lock(&vn->sock_lock);
- hlist_del_rcu(&vxlan->hlist);
+ if (!hlist_unhashed(&vxlan->hlist))
+ hlist_del_rcu(&vxlan->hlist);
spin_unlock(&vn->sock_lock);
list_del(&vxlan->next);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next v7 0/8] openvswitch: VXLAN tunneling.
From: Pravin B Shelar @ 2013-08-19 18:22 UTC (permalink / raw)
To: netdev, davem; +Cc: stephen, Pravin B Shelar
First four vxlan patches extends vxlan so that openvswitch
can share vxlan recv code. Rest of patches refactors vxlan
data plane so that ovs can share that code with vxlan module.
Last patch adds vxlan-vport to openvswitch.
v7 fixed first patch as suggested by Stephen Hemminger.
v6 series splits second patch into two and has few style fixes.
v5 series disallow any udp port sharing between
kernel-vxlan and ovs-vxlan as suggested by Stephen Hemminger.
Pravin B Shelar (8):
vxlan: Restructure vxlan socket apis.
vxlan: Restructure vxlan receive.
vxlan: Add vxlan recv demux.
vxlan: Extend vxlan handlers for openvswitch.
vxlan: Factor out vxlan send api.
vxlan: Improve vxlan headroom calculation.
vxlan: Add tx-vlan offload support.
openvswitch: Add vxlan tunneling support.
drivers/net/vxlan.c | 342 ++++++++++++++++++++++----------------
include/net/vxlan.h | 39 +++++
include/uapi/linux/openvswitch.h | 11 ++
net/openvswitch/Kconfig | 13 ++
net/openvswitch/Makefile | 4 +
net/openvswitch/vport-vxlan.c | 204 +++++++++++++++++++++++
net/openvswitch/vport.c | 3 +
net/openvswitch/vport.h | 1 +
8 files changed, 477 insertions(+), 140 deletions(-)
create mode 100644 include/net/vxlan.h
create mode 100644 net/openvswitch/vport-vxlan.c
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Corey Hickey @ 2013-08-19 18:22 UTC (permalink / raw)
To: Christoph Paasch
Cc: Eric Dumazet, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <20130819123314.GC3583@cpaasch-mac>
On 2013-08-19 05:33, Christoph Paasch wrote:
> Hello,
>
> I would say, the problem is due to a sequence-number rewriting
> middlebox, who does not correctly handle the SACK-blocks.
>
> In remote.pcap, you see:
> Packet#10: A Dup-ACK: ACK 1005503816, SACK: 1005505184-1005505648
> The SACK actually covers Packet#9
>
> In tun0.pcap, you have:
> Packet#9: The one that is SACK'ed: SEQ: 3514869772
> Packet#11: The Dup-ACK: ACK: 3514868404, SACK: 3570452498-3570452962
>
> You can see that the SACK-block is not really aligned with the ACK-numbers.
>
> Netfilter is probably dropping the Dup-ACK, because the SACK-block is
> acknowledging unseen data.
>
>
> There are middleboxes out there that randomize the sequence numbers, due to
> an old bug in Windows, where the initial sequence number was not
> sufficiently randomized. There are some of these middleboxes, who simply do
> not support SACK, thus modify only the sequence numbers of the TCP-header
> (https://supportforums.cisco.com/docs/DOC-12668#TCP_Sequence_Number_Randomization_and_SACK).
>
> This results in a TCP retransmission timeout on the sender, because of
> the invalid SACK-blocks, the duplicate ACKs are not accounted. This
> completly kills the performance, as you can see in our presentation given at
> IETF87: http://tools.ietf.org/agenda/87/slides/slides-87-tcpm-11.pdf
This makes good sense. I normally look at these in wireshark with
relative sequence numbers turned on, and I see in bad/tun0.pcap that the
SACK values are very high, but are normal in bad/remote.pcap.
I see the same thing in good/tun0.pcap, though, so I don't fully
understand what is making it work sometimes and not others.
I will show this thread and the Cisco docs to the network engineer at
work, and maybe we can get the SEQ randomization turned off (or at least
test it).
> We have a patch that accounts DUP-ACKs with invalid SACK-blocks effectively
> as duplicate acknowledgments. I can send the patches, if the
> netdev-community is interested in accepting these upstream.
I'll keep my eye out and test them if they come up.
Thanks,
Corey
^ permalink raw reply
* Re: [PATCH net] net-packet: restore packet statistics tp_packets to include drops
From: Sergei Shtylyov @ 2013-08-19 18:22 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: davem, dborkman, netdev
In-Reply-To: <1376855916-21824-1-git-send-email-willemb@google.com>
Hello.
On 08/18/2013 11:58 PM, Willem de Bruijn wrote:
> getsockopt PACKET_STATISTICS returns tp_packets + tp_drops.
> Commit ee80fbf301 cleaned up the getsockopt PACKET_STATISTICS code.
Please also specify that commit's summary in parens.
> This also changed semantics. Historically, tp_packets included
> tp_drops on return. The commit removed the line that adds tp_drops
> into tp_packets.
> This patch reinstates the old semantics.
> Signed-off-by: Willem de Bruijn <willemb@google.com>
WBR, Sergei
^ permalink raw reply
* Re: [GLIBC Patch v2] inet: avoid redefinition of some structs in kernel
From: Carlos O'Donell @ 2013-08-19 18:11 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, David S. Miller, Thomas Backlund, libc-alpha,
YOSHIFUJI Hideaki
In-Reply-To: <1376875250.2742.2.camel@cr0>
On 08/18/2013 09:20 PM, Cong Wang wrote:
> On Fri, 2013-08-16 at 11:47 -0400, Carlos O'Donell wrote:
>> On 08/15/2013 05:28 AM, Cong Wang wrote:
>>> 2013-08-13 Carlos O'Donell <carlos@redhat.com>
>>> Cong Wang <amwang@redhat.com>
>>>
>>> * sysdeps/unix/sysv/linux/bits/in.h
>>> [_UAPI_LINUX_IN6_H]: Define __USE_KERNEL_IPV6_DEFS.
>>> * inet/netinet/in.h: Move in_addr definition and bits/in.h inclusion
>>> before __USE_KERNEL_IPV6_DEFS uses.
>>> * inet/netinet/in.h [!__USE_KERNEL_IPV6_DEFS]: Define IPPROTO_MH, and
>>> IPPROTO_BEETPH.
>>> [__USE_KERNEL_IPV6_DEFS]: Don't define any of IPPROTO_*, in6_addr,
>>> sockaddr_in6, or ipv6_mreq.
>>
>> Cong,
>>
>> Given that this is a user visible change could you please file
>> a glibc bugzilla bug in sourceware[1] so we can track the commit and so
>> that future users can reopen the bug to discuss any defects?
>
> Done, http://sourceware.org/bugzilla/show_bug.cgi?id=15850
Perfect.
>>
>> Then you need to add the BZ# to the ChangeLog, and whomever
>> commits this for you will mark it fixed in the NEWS. We should
>> also write up a NEWS blurb for this since it's the first explicit
>> header coordination of it's kind and we should highlight that
>> so developers take note and help us coordinate more headers.
>>
>
> Should I resend this patch with BZ# included?
No need. But the final ChangeLog should have the BZ# in it, and the
committer will add it to the NEWS list of bugs fixed in 2.19.
Cheers,
Carlos.
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Eric Dumazet @ 2013-08-19 18:10 UTC (permalink / raw)
To: Christoph Paasch
Cc: Phil Oester, Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <20130819171519.GA4008@cpaasch-mac>
On Mon, 2013-08-19 at 19:15 +0200, Christoph Paasch wrote:
>
> Will send it soon. Have to rebase on net-next,... :)
> (it's several months ago that I did this)
No hurry.
This is a very unlikely problem anyway.
Trace taken on a random Google server :
TcpExtTCPSACKDiscard 44666
TcpExtTCPSACKReneging 173593
TcpExtTCPSACKReorder 1331306
TcpExtTCPSackFailures 791292
TcpExtTCPSackMerged 261702691
TcpExtTCPSackRecovery 57267494
TcpExtTCPSackRecoveryFail 2008511
TcpExtTCPSackShiftFallback 841017416
TcpExtTCPSackShifted 619337144
...
TcpOutSegs 42215528084
TcpRetransSegs 441868477
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Phil Oester @ 2013-08-19 18:00 UTC (permalink / raw)
To: Christoph Paasch
Cc: Eric Dumazet, Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <20130819171519.GA4008@cpaasch-mac>
On Mon, Aug 19, 2013 at 07:15:19PM +0200, Christoph Paasch wrote:
> On 19/08/13 - 09:00:31, Eric Dumazet wrote:
> > On Mon, 2013-08-19 at 17:33 +0200, Christoph Paasch wrote:
> > > Unfortunately, they will hardly go away in the near futur. Rather the
> > > opposite is the case.
> > >
> > >
> > > If you have a public server running, I would be interested in the count of
> > > invalid SACK-blocks received (netstat -s | grep TCPSACKDiscard). This is an
> > > indication for such kind of middlebox between your server and the client,
> > > implying that these connections cannot benefit from TCP-FastRetransmission
> > > and each packet-loss will require an RTO to recover.
> > >
> >
> > If the (random) sequence offset is small rather than completely out of
> > window, it's going to be hard to detect all problems.
It is not small unfortunately. The bug is that with ISN randomization enabled
the PIX leaves the SACK sequence numbers untouched. For reference, the cisco
bug is CSCse14419.
> Yes, it is not possible to make it 100% perfect. But considering the size of
> the seq-space, the probability is rather low that the SACK-block falls
> in-window.
s/rather low/nil/
> > Show us your patch ;)
Or just disable SACK on the box behind the problematic PIX.
Phil
^ permalink raw reply
* Re: [RFC][PATCH 2/2] bgmac: pass received packet to the netif instead of copying it
From: Rafał Miłecki @ 2013-08-19 17:20 UTC (permalink / raw)
To: Felix Fietkau
Cc: Network Development, Jonas Gorski, Hauke Mehrtens,
OpenWrt Development List
In-Reply-To: <5211A0CB.70003@openwrt.org>
2013/8/19 Felix Fietkau <nbd@openwrt.org>:
> On 2013-08-15 10:21 PM, Rafał Miłecki wrote:
>> I'm afraid this "perf top" output doesn't really tell us where to look
>> for optimizations :| I'll still try Felix ideas tomorrow, but I'm not
>> sure if they help, since there isn't __copy_user_common anymore in the
>> "perf top" output...
> What's the CPU load while passing traffic without running perf?
During "ping 192.168.5.1"
# top
Mem: 19564K used, 107076K free, 0K shrd, 0K buff, 12916K cached
CPU: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq
Load average: 0.17 0.10 0.04 1/24 810
# perf top
PerfTop: 261 irqs/sec kernel:100.0% exact: 0.0% [4000Hz cycles], (all, 1 CPU)
-------------------------------------------------------------------------------
64.21% [kernel] [k] arch_cpu_idle
16.38% [kernel] [k] arch_local_irq_restore
12.01% [kernel] [k] cpu_startup_entry
2.16% [kernel] [k] rcu_idle_exit
During "iperf -c 192.168.5.1"
# top
Mem: 19572K used, 107068K free, 0K shrd, 0K buff, 12916K cached
CPU: 0% usr 0% sys 0% nic 3% idle 0% io 0% irq 96% sirq
Load average: 0.29 0.11 0.04 1/24 809
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
3 2 root RW 0 0% 9% [ksoftirqd/0]
809 376 root R 1496 1% 2% top
716 1 nobody S 964 1% 1% /usr/sbin/dnsmasq -C /var/etc/dnsmasq
# perf top
PerfTop: 265 irqs/sec kernel:100.0% exact: 0.0% [4000Hz cycles], (all, 1 CPU)
-------------------------------------------------------------------------------
6.41% [ip_tables] [k] ipt_do_table
4.01% [bgmac] [k] 0x000006ec
3.43% [kernel] [k] arch_cpu_idle
3.30% [kernel] [k] arch_local_irq_restore
3.25% [kernel] [k] ip_rcv
3.11% [nf_conntrack] [k] nf_conntrack_proto_fini
3.11% [nf_conntrack] [k] nf_conntrack_in
> Have you tested bridging performance?
Do you mean connecting both machines to the same VLAN? Like 2 LAN
ports in the standard configuration? It gives me ~600Mb/s using
OpenWrt. It's pretty much the same performance I got with the original
firmware for transfer between 2 VLANs.
[ 5] local 192.168.1.218 port 5001 connected with 192.168.1.131 port 59463
[ 5] 0.0-60.0 sec 4.16 GBytes 596 Mbits/sec
--
Rafał
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Christoph Paasch @ 2013-08-19 17:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Phil Oester, Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <1376928031.4226.66.camel@edumazet-glaptop>
On 19/08/13 - 09:00:31, Eric Dumazet wrote:
> On Mon, 2013-08-19 at 17:33 +0200, Christoph Paasch wrote:
> > Unfortunately, they will hardly go away in the near futur. Rather the
> > opposite is the case.
> >
> >
> > If you have a public server running, I would be interested in the count of
> > invalid SACK-blocks received (netstat -s | grep TCPSACKDiscard). This is an
> > indication for such kind of middlebox between your server and the client,
> > implying that these connections cannot benefit from TCP-FastRetransmission
> > and each packet-loss will require an RTO to recover.
> >
>
> If the (random) sequence offset is small rather than completely out of
> window, it's going to be hard to detect all problems.
Yes, it is not possible to make it 100% perfect. But considering the size of
the seq-space, the probability is rather low that the SACK-block falls
in-window.
> Show us your patch ;)
Will send it soon. Have to rebase on net-next,... :)
(it's several months ago that I did this)
Christoph
^ permalink raw reply
* [PATCH] batman-adv: check return type of unicast packet preparations
From: Antonio Quartulli @ 2013-08-19 16:59 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Linus Lüssing, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1376931595-2070-1-git-send-email-ordex@autistici.org>
From: Linus Lüssing <linus.luessing@web.de>
batadv_unicast(_4addr)_prepare_skb might reallocate the skb's data.
And if it tries to do so then this can potentially fail.
We shouldn't continue working on this skb in such a case.
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Acked-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
---
net/batman-adv/unicast.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/batman-adv/unicast.c b/net/batman-adv/unicast.c
index 688a041..857e1b8 100644
--- a/net/batman-adv/unicast.c
+++ b/net/batman-adv/unicast.c
@@ -432,12 +432,16 @@ find_router:
switch (packet_type) {
case BATADV_UNICAST:
- batadv_unicast_prepare_skb(skb, orig_node);
+ if (!batadv_unicast_prepare_skb(skb, orig_node))
+ goto out;
+
header_len = sizeof(struct batadv_unicast_packet);
break;
case BATADV_UNICAST_4ADDR:
- batadv_unicast_4addr_prepare_skb(bat_priv, skb, orig_node,
- packet_subtype);
+ if (!batadv_unicast_4addr_prepare_skb(bat_priv, skb, orig_node,
+ packet_subtype))
+ goto out;
+
header_len = sizeof(struct batadv_unicast_4addr_packet);
break;
default:
--
1.8.1.5
^ permalink raw reply related
* pull request net: 2013-08-19
From: Antonio Quartulli @ 2013-08-19 16:59 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
Hi David,
after a not so quiet weekend, here is my small pull request intended for
net/linux-3.11.
This is a fix that aims to block TX operations in case of skb preparation
failure.
Please pull or let me know of any problem.
Thanks,
Antonio
p.s. is net going to be merged into net-next one of these days? I need it in
order to send a couple of changes to net-next.
The following changes since commit 0f7dd1aa8f959216f1faa71513b9d3c1a9065e5a:
Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux (2013-08-16 10:00:18 -0700)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem
for you to fetch changes up to 50fa3b31f4700deb1a860fa1a04016b889765323:
batman-adv: check return type of unicast packet preparations (2013-08-17 20:02:32 +0200)
----------------------------------------------------------------
Included change:
- Check if the skb has been correctly prepared before going on
----------------------------------------------------------------
Linus Lüssing (1):
batman-adv: check return type of unicast packet preparations
net/batman-adv/unicast.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Eric Dumazet @ 2013-08-19 16:00 UTC (permalink / raw)
To: Christoph Paasch
Cc: Phil Oester, Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <20130819153328.GH3583@cpaasch-mac>
On Mon, 2013-08-19 at 17:33 +0200, Christoph Paasch wrote:
>
> Unfortunately, they will hardly go away in the near futur. Rather the
> opposite is the case.
>
>
> If you have a public server running, I would be interested in the count of
> invalid SACK-blocks received (netstat -s | grep TCPSACKDiscard). This is an
> indication for such kind of middlebox between your server and the client,
> implying that these connections cannot benefit from TCP-FastRetransmission
> and each packet-loss will require an RTO to recover.
>
If the (random) sequence offset is small rather than completely out of
window, it's going to be hard to detect all problems.
Show us your patch ;)
^ permalink raw reply
* Re: [PATCH] ip: Add label option to ip monitor
From: Stephen Hemminger @ 2013-08-19 15:58 UTC (permalink / raw)
To: Martin Schwenke; +Cc: netdev
In-Reply-To: <20130819154330.77c29d55@martins.ozlabs.org>
On Mon, 19 Aug 2013 15:43:30 +1000
Martin Schwenke <martin@meltin.net> wrote:
> Prefix labelling is currently only activated when monitoring "all"
> objects. However, the output can still be confusing when monitoring
> more than 1 object, so add an option to always print prefix labels.
>
> Signed-off-by: Martin Schwenke <martin@meltin.net>
> ---
> Really a reply to http://www.spinics.net/lists/netdev/msg246739.html
Thanks, applied.
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Christoph Paasch @ 2013-08-19 15:33 UTC (permalink / raw)
To: Phil Oester
Cc: Eric Dumazet, Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <20130819143509.GA31320@linuxace.com>
On 19/08/13 - 07:35:09, Phil Oester wrote:
> On Mon, Aug 19, 2013 at 06:58:05AM -0700, Eric Dumazet wrote:
> > Yeah, but here, this is conntrack who is blocking the thing.
> >
> > TCP receiver has no chance to 'fix' it.
> >
> > See conntrack is one of those buggy middle box as well.
> >
> > So if you want to properly handle this mess, you'll also have to fix
> > conntrack.
>
> Better to fix the box which is randomizing the acks and ignoring
> the SACKs. Usually these are older Cisco PIX/ASA devices which just
> need a code upgrade.
I agree, the problem are these horrid middleboxes...
Unfortunately, they will hardly go away in the near futur. Rather the
opposite is the case.
If you have a public server running, I would be interested in the count of
invalid SACK-blocks received (netstat -s | grep TCPSACKDiscard). This is an
indication for such kind of middlebox between your server and the client,
implying that these connections cannot benefit from TCP-FastRetransmission
and each packet-loss will require an RTO to recover.
Cheers,
Christoph
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Eric Dumazet @ 2013-08-19 15:32 UTC (permalink / raw)
To: Phil Oester
Cc: Christoph Paasch, Corey Hickey, Jozsef Kadlecsik,
Linux Netdev List, netfilter-devel
In-Reply-To: <20130819143509.GA31320@linuxace.com>
On Mon, 2013-08-19 at 07:35 -0700, Phil Oester wrote:
> On Mon, Aug 19, 2013 at 06:58:05AM -0700, Eric Dumazet wrote:
> > Yeah, but here, this is conntrack who is blocking the thing.
> >
> > TCP receiver has no chance to 'fix' it.
> >
> > See conntrack is one of those buggy middle box as well.
> >
> > So if you want to properly handle this mess, you'll also have to fix
> > conntrack.
>
> Better to fix the box which is randomizing the acks and ignoring
> the SACKs. Usually these are older Cisco PIX/ASA devices which just
> need a code upgrade.
Having a patch to relax things could be evaluated, if not adding new
problems ( http://en.wikipedia.org/wiki/Robustness_principle )
^ permalink raw reply
* [PATCH 4/4] tun: Get skfilter layout
From: Pavel Emelyanov @ 2013-08-19 15:10 UTC (permalink / raw)
To: Linux Netdev List, David Miller
In-Reply-To: <52123515.3060507@parallels.com>
The only thing we may have from tun device is the fprog, whic contains
the number of filter elements and a pointer to (user-space) memory
where the elements are. The program itself may not be available if the
device is persistent and detached.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
drivers/net/tun.c | 10 ++++++++++
include/uapi/linux/if_tun.h | 1 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8bfc1ce..eb48157 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2042,6 +2042,16 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
tun_detach_filter(tun, tun->numqueues);
break;
+ case TUNGETFILTER:
+ ret = -EINVAL;
+ if ((tun->flags & TUN_TYPE_MASK) != TUN_TAP_DEV)
+ break;
+ ret = -EFAULT;
+ if (copy_to_user(argp, &tun->fprog, sizeof(tun->fprog)))
+ break;
+ ret = 0;
+ break;
+
default:
ret = -EINVAL;
break;
diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
index cc127b2..e9502dd 100644
--- a/include/uapi/linux/if_tun.h
+++ b/include/uapi/linux/if_tun.h
@@ -57,6 +57,7 @@
#define TUNSETVNETHDRSZ _IOW('T', 216, int)
#define TUNSETQUEUE _IOW('T', 217, int)
#define TUNSETIFINDEX _IOW('T', 218, unsigned int)
+#define TUNGETFILTER _IOR('T', 219, struct sock_fprog)
/* TUNSETIFF ifr flags */
#define IFF_TUN 0x0001
--
1.7.6.5
^ permalink raw reply related
* [PATCH 3/4] tun: Allow to skip filter on attach
From: Pavel Emelyanov @ 2013-08-19 15:10 UTC (permalink / raw)
To: Linux Netdev List, David Miller
In-Reply-To: <52123515.3060507@parallels.com>
There's a small problem with sk-filters on tun devices. Consider
an application doing this sequence of steps:
fd = open("/dev/net/tun");
ioctl(fd, TUNSETIFF, { .ifr_name = "tun0" });
ioctl(fd, TUNATTACHFILTER, &my_filter);
ioctl(fd, TUNSETPERSIST, 1);
close(fd);
At that point the tun0 will remain in the system and will keep in
mind that there should be a socket filter at address '&my_filter'.
If after that we do
fd = open("/dev/net/tun");
ioctl(fd, TUNSETIFF, { .ifr_name = "tun0" });
we most likely receive the -EFAULT error, since tun_attach() would
try to connect the filter back. But (!) if we provide a filter at
address &my_filter, then tun0 will be created and the "new" filter
would be attached, but application may not know about that.
This may create certain problems to anyone using tun-s, but it's
critical problem for c/r -- if we meet a persistent tun device
with a filter in mind, we will not be able to attach to it to dump
its state (flags, owner, address, vnethdr size, etc.).
The proposal is to allow to attach to tun device (with TUNSETIFF)
w/o attaching the filter to the tun-file's socket. After this
attach app may e.g clean the device by dropping the filter, it
doesn't want to have one, or (in case of c/r) get information
about the device with tun ioctls.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
drivers/net/tun.c | 12 +++++++-----
include/uapi/linux/if_tun.h | 1 +
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 167222f..8bfc1ce 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -501,7 +501,7 @@ static void tun_detach_all(struct net_device *dev)
module_put(THIS_MODULE);
}
-static int tun_attach(struct tun_struct *tun, struct file *file)
+static int tun_attach(struct tun_struct *tun, struct file *file, bool skip_filter)
{
struct tun_file *tfile = file->private_data;
int err;
@@ -526,7 +526,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
err = 0;
/* Re-attach the filter to presist device */
- if (tun->filter_attached == true) {
+ if (!skip_filter && (tun->filter_attached == true)) {
err = sk_attach_filter(&tun->fprog, tfile->socket.sk);
if (!err)
goto out;
@@ -1557,7 +1557,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (err < 0)
return err;
- err = tun_attach(tun, file);
+ err = tun_attach(tun, file, ifr->ifr_flags & IFF_NOFILTER);
if (err < 0)
return err;
@@ -1631,7 +1631,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
dev->vlan_features = dev->features;
INIT_LIST_HEAD(&tun->disabled);
- err = tun_attach(tun, file);
+ err = tun_attach(tun, file, false);
if (err < 0)
goto err_free_dev;
@@ -1795,7 +1795,7 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
ret = security_tun_dev_attach_queue(tun->security);
if (ret < 0)
goto unlock;
- ret = tun_attach(tun, file);
+ ret = tun_attach(tun, file, false);
} else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
tun = rtnl_dereference(tfile->tun);
if (!tun || !(tun->flags & TUN_TAP_MQ) || tfile->detached)
@@ -1883,6 +1883,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
if (tfile->detached)
ifr.ifr_flags |= IFF_DETACH_QUEUE;
+ if (!tfile->socket.sk->sk_filter)
+ ifr.ifr_flags |= IFF_NOFILTER;
if (copy_to_user(argp, &ifr, ifreq_len))
ret = -EFAULT;
diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
index c58d023..cc127b2 100644
--- a/include/uapi/linux/if_tun.h
+++ b/include/uapi/linux/if_tun.h
@@ -71,6 +71,7 @@
#define IFF_DETACH_QUEUE 0x0400
/* read-only flag */
#define IFF_PERSIST 0x0800
+#define IFF_NOFILTER 0x1000
/* Socket options */
#define TUN_TX_TIMESTAMP 1
--
1.7.6.5
^ permalink raw reply related
* [PATCH 2/4] tun: Report whether the queue is attached or not
From: Pavel Emelyanov @ 2013-08-19 15:09 UTC (permalink / raw)
To: Linux Netdev List, David Miller
In-Reply-To: <52123515.3060507@parallels.com>
Multiqueue tun devices allow to attach and detach from its queues
while keeping the interface itself set on file.
Knowing this is critical for the checkpoint part of criu project.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
drivers/net/tun.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index a12450b..167222f 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1881,6 +1881,9 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
case TUNGETIFF:
tun_get_iff(current->nsproxy->net_ns, tun, &ifr);
+ if (tfile->detached)
+ ifr.ifr_flags |= IFF_DETACH_QUEUE;
+
if (copy_to_user(argp, &ifr, ifreq_len))
ret = -EFAULT;
break;
--
1.7.6.5
^ permalink raw reply related
* [PATCH 1/4] tun: Add ability to create tun device with given index
From: Pavel Emelyanov @ 2013-08-19 15:09 UTC (permalink / raw)
To: Linux Netdev List, David Miller
In-Reply-To: <52123515.3060507@parallels.com>
Tun devices cannot be created with ifidex user wants, but it's
required by checkpoint-restore project.
Long time ago such ability was implemented for rtnl_ops-based
interface for creating links (9c7dafbf net: Allow to create links
with given ifindex), but the only API for creating and managing
tuntap devices is ioctl-based and is evolving with adding new ones
(cde8b15f tuntap: add ioctl to attach or detach a file form tuntap
device).
Following that trend, here's how a new ioctl that sets the ifindex
for device, that _will_ be created by TUNSETIFF ioctl looks like.
So those who want a tuntap device with the ifindex N, should open
the tun device, call ioctl(fd, TUNSETIFINDEX, &N), then call TUNSETIFF.
If the index N is busy, then the register_netdev will find this out
and the ioctl would be failed with -EBUSY.
If setifindex is not called, then it will be generated as before.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
drivers/net/tun.c | 21 ++++++++++++++++++++-
include/uapi/linux/if_tun.h | 1 +
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 7ed13cc..a12450b 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -138,7 +138,10 @@ struct tun_file {
struct fasync_struct *fasync;
/* only used for fasnyc */
unsigned int flags;
- u16 queue_index;
+ union {
+ u16 queue_index;
+ unsigned ifindex;
+ };
struct list_head next;
struct tun_struct *detached;
};
@@ -1601,6 +1604,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
dev_net_set(dev, net);
dev->rtnl_link_ops = &tun_link_ops;
+ dev->ifindex = tfile->ifindex;
tun = netdev_priv(dev);
tun->dev = dev;
@@ -1817,6 +1821,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
kgid_t group;
int sndbuf;
int vnet_hdr_sz;
+ unsigned ifindex;
int ret;
if (cmd == TUNSETIFF || cmd == TUNSETQUEUE || _IOC_TYPE(cmd) == 0x89) {
@@ -1851,6 +1856,19 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
ret = -EFAULT;
goto unlock;
}
+ if (cmd == TUNSETIFINDEX) {
+ ret = -EPERM;
+ if (tun)
+ goto unlock;
+
+ ret = -EFAULT;
+ if (copy_from_user(&ifindex, argp, sizeof(ifindex)))
+ goto unlock;
+
+ ret = 0;
+ tfile->ifindex = ifindex;
+ goto unlock;
+ }
ret = -EBADFD;
if (!tun)
@@ -2099,6 +2117,7 @@ static int tun_chr_open(struct inode *inode, struct file * file)
rcu_assign_pointer(tfile->tun, NULL);
tfile->net = get_net(current->nsproxy->net_ns);
tfile->flags = 0;
+ tfile->ifindex = 0;
rcu_assign_pointer(tfile->socket.wq, &tfile->wq);
init_waitqueue_head(&tfile->wq.wait);
diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
index 1870ee2..c58d023 100644
--- a/include/uapi/linux/if_tun.h
+++ b/include/uapi/linux/if_tun.h
@@ -56,6 +56,7 @@
#define TUNGETVNETHDRSZ _IOR('T', 215, int)
#define TUNSETVNETHDRSZ _IOW('T', 216, int)
#define TUNSETQUEUE _IOW('T', 217, int)
+#define TUNSETIFINDEX _IOW('T', 218, unsigned int)
/* TUNSETIFF ifr flags */
#define IFF_TUN 0x0001
--
1.7.6.5
^ permalink raw reply related
* [PATCH net-next 0/4] tun: Some bits required for tun's checkpoint-restore
From: Pavel Emelyanov @ 2013-08-19 15:09 UTC (permalink / raw)
To: Linux Netdev List, David Miller
Hi,
After taking a closer look on tun checkpoint-restore I've found several
issues with the tun's API that make it impossible to dump and restore
the state of tun device and attached tun-files.
The proposed API changes are all about extending the existing ioctl-based
stuff. Patches fit today's net-next.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
^ permalink raw reply
* Re: [PATCH 6/7] net: add the AF_FLEXRAY protocol
From: Schmitt, Sven (EVM/E) @ 2013-08-19 15:00 UTC (permalink / raw)
To: 'b.spranger@linutronix.de'; +Cc: 'netdev@vger.kernel.org'
On 13.08.2013 11:08, Benedikt Spranger wrote:
> FlexRay is a networking technology used in automotive fields as
> successor of the Controller Area Network (CAN). It provides the
> core functionality and a RAW protocol driver.
>
> Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
> ---
> Documentation/networking/00-INDEX | 2 +
> Documentation/networking/flexray.txt | 24 ++
> include/linux/flexray.h | 168 ++++++++
Hello Benedikt,
thanks for bringing flexray to linux.
Some general remarks/questions:
- how can errors (crc, boundary, tx on not empty slot) be transported by the frame like in a CAN frame (/include/uapi/linux/can/error.h):
-> canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */ ?
...there is no more space in the id field in your frame definition.
- what about special bus content like wakeup pattern (WUP), collision avoidance symbol (CAS) and media test symbols (MTS). These are interesting for logging use cases.
- do we need the crc fields? What happens if the cr check fails (-> error flag)? Do we need this information then?
- do we need the reserved bit? (there is none in CAN frame definition)
Best regards,
Sven
^ permalink raw reply
* Re: [Patch net-next v3 8/9] sctp: use generic union inet_addr
From: Vlad Yasevich @ 2013-08-19 15:05 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, David S. Miller, Daniel Borkmann, Neil Horman, linux-sctp
In-Reply-To: <1376907278-26377-9-git-send-email-amwang@redhat.com>
On 08/19/2013 06:14 AM, Cong Wang wrote:
> From: Cong Wang <amwang@redhat.com>
>
> sctp has its own union sctp_addr which is nearly same
> with the generic union inet_addr, so just convert it
> to the generic one.
>
> Sorry for the big patch, it is not easy to split it. Most
> of the patch simply does s/union sctp_addr/union inet_addr/
> and some adjustments for the fields.
>
> The address family specific ops, ->cmp_addr(), ->is_any() etc.,
> are removed, since we have generic helpers, they are unnecessary.
You are not actually removing cmp_addr(), so that's invalid.
For the usage of ->is_any, see below.
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 422db6c..8dfaa39 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -1117,10 +1105,10 @@ union sctp_params sctp_bind_addrs_to_raw(const struct sctp_bind_addr *bp,
> int sctp_raw_to_bind_addrs(struct sctp_bind_addr *bp, __u8 *raw, int len,
> __u16 port, gfp_t gfp);
>
> -sctp_scope_t sctp_scope(const union sctp_addr *);
> -int sctp_in_scope(struct net *net, const union sctp_addr *addr, const sctp_scope_t scope);
> -int sctp_is_any(struct sock *sk, const union sctp_addr *addr);
> -int sctp_addr_is_valid(const union sctp_addr *addr);
> +sctp_scope_t sctp_scope(const union inet_addr *);
> +int sctp_in_scope(struct net *net, const union inet_addr *addr, const sctp_scope_t scope);
> +int sctp_is_any(struct sock *sk, const union inet_addr *addr);
You are keeping the prototype and remove the implementation of
sctp_is_any later, but that's ok since I don't think the implementation
should be removed. However, this points out that this should probably
be a separate patch (first do straight conversion to new data structure,
then fix up usage and delete unneeded functions).
> +int sctp_addr_is_valid(const union inet_addr *addr);
> int sctp_is_ep_boundall(struct sock *sk);
>
>
> diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c
> index 077bb07..03d8f85 100644
> --- a/net/sctp/bind_addr.c
> +++ b/net/sctp/bind_addr.c
> @@ -47,7 +47,7 @@
> @@ -436,13 +436,13 @@ union sctp_addr *sctp_find_unmatch_addr(struct sctp_bind_addr *bp,
>
> /* Copy out addresses from the global local address list. */
> static int sctp_copy_one_addr(struct net *net, struct sctp_bind_addr *dest,
> - union sctp_addr *addr,
> + union inet_addr *addr,
> sctp_scope_t scope, gfp_t gfp,
> int flags)
> {
> int error = 0;
>
> - if (sctp_is_any(NULL, addr)) {
> + if (inet_addr_any(addr)) {
> error = sctp_copy_local_addr_list(net, dest, scope, gfp, flags);
> } else if (sctp_in_scope(net, addr, scope)) {
> /* Now that the address is in scope, check to see if
> @@ -461,27 +461,8 @@ static int sctp_copy_one_addr(struct net *net, struct sctp_bind_addr *dest,
> return error;
> }
>
> -/* Is this a wildcard address? */
> -int sctp_is_any(struct sock *sk, const union sctp_addr *addr)
> -{
> - unsigned short fam = 0;
> - struct sctp_af *af;
> -
> - /* Try to get the right address family */
> - if (addr->sa.sa_family != AF_UNSPEC)
> - fam = addr->sa.sa_family;
> - else if (sk)
> - fam = sk->sk_family;
> -
> - af = sctp_get_af_specific(fam);
> - if (!af)
> - return 0;
> -
> - return af->is_any(addr);
> -}
> -
I don't think you can remove this implentation. It is would introduce
a lot of regressions for code that does:
struct sockaddr_in sin;
memset(&sin, 0, sizeof(sin));
/* Do some setsockopt... with sin */
While I do agree that this is a bit sloppy (and I've made that argument
to all the bug submitters), this type of bug has been reported for a
long time and sctp_is_any() was finally changed to fix it once and for
all. You are un-fixing it...
> /* Is 'addr' valid for 'scope'? */
> -int sctp_in_scope(struct net *net, const union sctp_addr *addr, sctp_scope_t scope)
> +int sctp_in_scope(struct net *net, const union inet_addr *addr, sctp_scope_t scope)
> {
> sctp_scope_t addr_scope = sctp_scope(addr);
>
> @@ -530,7 +511,7 @@ int sctp_is_ep_boundall(struct sock *sk)
> if (sctp_list_single_entry(&bp->address_list)) {
> addr = list_entry(bp->address_list.next,
> struct sctp_sockaddr_entry, list);
> - if (sctp_is_any(sk, &addr->a))
> + if (inet_addr_any(&addr->a))
> return 1;
> }
> return 0;
> diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
> index da613ce..2e1262b 100644
> --- a/net/sctp/ipv6.c
> +++ b/net/sctp/ipv6.c
>
> /* Compare addresses exactly.
> * v4-mapped-v6 is also in consideration.
> */
> -static int sctp_v6_cmp_addr(const union sctp_addr *addr1,
> - const union sctp_addr *addr2)
> +static bool sctp_v6_cmp_addr(const union inet_addr *addr1,
> + const union inet_addr *addr2)
> {
> if (addr1->sa.sa_family != addr2->sa.sa_family) {
> if (addr1->sa.sa_family == AF_INET &&
> addr2->sa.sa_family == AF_INET6 &&
> - ipv6_addr_v4mapped(&addr2->v6.sin6_addr)) {
> - if (addr2->v6.sin6_port == addr1->v4.sin_port &&
> - addr2->v6.sin6_addr.s6_addr32[3] ==
> - addr1->v4.sin_addr.s_addr)
> + ipv6_addr_v4mapped(&addr2->sin6.sin6_addr)) {
> + if (addr2->sin6.sin6_port == addr1->sin.sin_port &&
> + addr2->sin6.sin6_addr.s6_addr32[3] ==
> + addr1->sin.sin_addr.s_addr)
> return 1;
> }
> if (addr2->sa.sa_family == AF_INET &&
> addr1->sa.sa_family == AF_INET6 &&
> - ipv6_addr_v4mapped(&addr1->v6.sin6_addr)) {
> - if (addr1->v6.sin6_port == addr2->v4.sin_port &&
> - addr1->v6.sin6_addr.s6_addr32[3] ==
> - addr2->v4.sin_addr.s_addr)
> + ipv6_addr_v4mapped(&addr1->sin6.sin6_addr)) {
> + if (addr1->sin6.sin6_port == addr2->sin.sin_port &&
> + addr1->sin6.sin6_addr.s6_addr32[3] ==
> + addr2->sin.sin_addr.s_addr)
> return 1;
> }
> return 0;
> }
> - if (!ipv6_addr_equal(&addr1->v6.sin6_addr, &addr2->v6.sin6_addr))
> - return 0;
> - /* If this is a linklocal address, compare the scope_id. */
> - if (ipv6_addr_type(&addr1->v6.sin6_addr) & IPV6_ADDR_LINKLOCAL) {
> - if (addr1->v6.sin6_scope_id && addr2->v6.sin6_scope_id &&
> - (addr1->v6.sin6_scope_id != addr2->v6.sin6_scope_id)) {
> - return 0;
> - }
> - }
> -
> - return 1;
> -}
>
> -/* Initialize addr struct to INADDR_ANY. */
> -static void sctp_v6_inaddr_any(union sctp_addr *addr, __be16 port)
> -{
> - memset(addr, 0x00, sizeof(union sctp_addr));
> - addr->v6.sin6_family = AF_INET6;
> - addr->v6.sin6_port = port;
> -}
> -
> -/* Is this a wildcard address? */
> -static int sctp_v6_is_any(const union sctp_addr *addr)
> -{
> - return ipv6_addr_any(&addr->v6.sin6_addr);
> + return inet_addr_equal(addr1, addr2);
You've dropped the scope_id comparision which inet_addr_equal does not
seem to do. As far as I can see from this series, inet_addr_equal()
just calls ipv6_addr_equal.
-vlad
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnx2x: add RSS capability for GRE traffic
From: Jerry Chu @ 2013-08-19 14:57 UTC (permalink / raw)
To: Eric Dumazet
Cc: Dmitry Kravkov, Dmitry Kravkov, davem@davemloft.net,
netdev@vger.kernel.org, Eilon Greenstein, Tom Herbert,
Maciej Żenczykowski, Uday Naik, Michael Dalton
In-Reply-To: <1376869493.4226.13.camel@edumazet-glaptop>
On Sun, Aug 18, 2013 at 4:44 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sun, 2013-08-18 at 14:11 -0700, Jerry Chu wrote:
>
>> It can if the csum validation is deferred. But this requires the stack code to
>> aggregate csum from individual pkt header, which can get ugly as one needs
>> to remove the header part from the individual csum first.
>
> You can _not_ aggregate packets _before_ validating their checksum, or
> else you could end up with a correct final checksum while two or more
> segments had buggy checksums. Checksum are already quite weak, please
> do not make them even weaker ;)
Yes I know how weak the 16bit 1's complement inet csum (see my previous email).
I've had the pleasure to debug a number of bugs in the past where 16bit words
were flipped by the buggy h/w hence went undetected by the weak TCP csum.
But I also think it's a tradeoff call. For WAN it's probably a bad
idea but for data
center traffic, pkt corruption is usually rare. If the performance
gain is large enough,
perhaps it justifies this hack (?)
>
> GRO should not throw out any segments, it is not its role.
I did not suggest GRO to throw away any pkt. GRO would just fix the csum
field in the header of the aggregated pkt and passes it on.
>
> If a router receives a bunch of packets, it should forward them
> regardless of the (TCP) checksum being good or not.
It won't affect the forwarding path (i think).
>
> The final receiver has full responsibility for ultimately validate the
> checksums and update various SNMP counters.
When the GRO pkt with the csum field fixed (aggregated) get to
the receiving TCP endpoint, it will be csum validated by the TCP stack
because skb->ip_summed == CHECKSUM_NONE, and the pkt will be
tossed if the csum check fails like non-GRO pkts.
To be clear, this hack is not something I'd be proud of and I doubt the
performance gain will be enough to justify it. This idea grew more out of
desperation for not having csum offload for encap'ed pkts, which I think
is a P0 bug!
Jerry
>
>
>
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Christoph Paasch @ 2013-08-19 14:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <1376920685.4226.61.camel@edumazet-glaptop>
On 19/08/13 - 06:58:05, Eric Dumazet wrote:
> On Mon, 2013-08-19 at 15:49 +0200, Christoph Paasch wrote:
> > It's a TCP-patch, that interprets duplicate-acks with invalid SACK-blocks as
> > duplicate acks in tcp_sock->sacked_out.
>
> Yeah, but here, this is conntrack who is blocking the thing.
Yes, of course. I know that here conntrack is blocking the dup-ACKs.
Sorry for having added TCP-stack specific things in a conntrack-thread.
I just wanted to highlight that the TCP-stack has also problems with
sequence-number rewriting middleboxes.
> TCP receiver has no chance to 'fix' it.
>
> See conntrack is one of those buggy middle box as well.
>
> So if you want to properly handle this mess, you'll also have to fix
> conntrack.
^ 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