* Re: [PATCH v2 net-next] pkt_sched: fq: better control of DDOS traffic
From: David Miller @ 2015-02-05 4:22 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1422984739.907.25.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 03 Feb 2015 09:32:19 -0800
> + if (tb[TCA_FQ_ORPHAN_MASK])
> + q->orphan_mask = nla_get_u32(tb[TCA_FQ_ORPHAN_MASK]);
This doesn't build, the header file changes that add TCA_FQ_ORPHAN_MASK
are missing from your patch.
^ permalink raw reply
* Re: [PATCH net 1/1] cls_api.c: Fix dumping of non-existing actions' stats.
From: David Miller @ 2015-02-05 4:26 UTC (permalink / raw)
To: ignacy.gawedzki; +Cc: netdev
In-Reply-To: <20150203173251.GB6246@zenon.in.qult.net>
From: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
Date: Tue, 3 Feb 2015 18:32:51 +0100
> In tcf_exts_dump_stats(), ensure that exts->actions is not empty before
> accessing the first element of that list and calling tcf_action_copy_stats()
> on it. This fixes some random segvs when adding filters of type "basic" with
> no particular action.
>
> This also fixes the dumping of those "no-action" filters, which more often
> than not made calls to tcf_action_copy_stats() fail and consequently netlink
> attributes added by the caller to be removed by a call to nla_nest_cancel().
>
> Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] amd-xgbe: Adjust for zero-based traffic class count
From: David Miller @ 2015-02-05 4:28 UTC (permalink / raw)
To: thomas.lendacky; +Cc: netdev
In-Reply-To: <20150203184955.14713.98160.stgit@tlendack-t1.amdoffice.net>
From: Tom Lendacky <thomas.lendacky@amd.com>
Date: Tue, 3 Feb 2015 12:49:55 -0600
> The number of traffic classes reported by the hardware is zero-based
> so increment the value returned to get an actual count.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Applied, thanks Tom.
^ permalink raw reply
* Re: [PATCH] IBM-EMAC: Delete an unnecessary check before the function call "of_dev_put"
From: David Miller @ 2015-02-05 4:29 UTC (permalink / raw)
To: elfring; +Cc: netdev, linux-kernel, kernel-janitors, julia.lawall
In-Reply-To: <54D118BA.3080001@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 03 Feb 2015 19:51:38 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 3 Feb 2015 19:47:33 +0100
>
> The of_dev_put() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Applied.
^ permalink raw reply
* Re: [PATCH] NetCP: Deletion of unnecessary checks before two function calls
From: David Miller @ 2015-02-05 4:30 UTC (permalink / raw)
To: elfring
Cc: m-karicheri2, w-kwok2, netdev, linux-kernel, kernel-janitors,
julia.lawall
In-Reply-To: <54D11FEF.10804@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 03 Feb 2015 20:22:23 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 3 Feb 2015 20:12:25 +0100
>
> The functions cpsw_ale_destroy() and of_dev_put() test whether their argument
> is NULL and then return immediately. Thus the test around the call
> is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Applied.
^ permalink raw reply
* Re: [PATCH net] amd-xgbe: Set RSS enablement based on hardware features
From: David Miller @ 2015-02-05 4:32 UTC (permalink / raw)
To: thomas.lendacky; +Cc: netdev
In-Reply-To: <20150203201432.18889.73945.stgit@tlendack-t1.amdoffice.net>
From: Tom Lendacky <thomas.lendacky@amd.com>
Date: Tue, 3 Feb 2015 14:14:32 -0600
> The RSS support requires enablement based on the features reported by
> the hardware. The setting of this flag is missing. Add support to
> set the RSS enablement flag based on the reported hardware features.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Applied, thanks Tom.
^ permalink raw reply
* Re: [PATCH 0/4] rhashtable: Add iterators and use them
From: David Miller @ 2015-02-05 4:35 UTC (permalink / raw)
To: herbert; +Cc: tgraf, netdev
In-Reply-To: <20150203203213.GA23177@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 4 Feb 2015 07:32:13 +1100
> On Wed, Feb 04, 2015 at 07:17:50AM +1100, Herbert Xu wrote:
>>
>> > ERROR: "rhashtable_walk_start" [net/netfilter/nft_hash.ko] undefined!
>>
>> Oops, I missed an export on that symbol. I'll fix it up and
>> repost.
>
> OK here is the repost without the hash_rnd patch.
>
> The first patch fixes a potential crash with nft_hash destroying
> the table during a shrinking process. While the next patch adds
> rhashtable iterators to replace current manual walks used by
> netlink and netfilter. The final two patches make use of these
> iterators in netlink and netfilter.
Series applied to net-next.
Please address the sparse locking warnings reported against patch #3, it's
probably just some missing acquire/release annotations.
^ permalink raw reply
* Re: [PATCH net-next] tcp: do not pace pure ack packets
From: David Miller @ 2015-02-05 4:36 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, kennetkl
In-Reply-To: <1423017113.907.76.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 03 Feb 2015 18:31:53 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> When we added pacing to TCP, we decided to let sch_fq take care
> of actual pacing.
>
> All TCP had to do was to compute sk->pacing_rate using simple formula:
>
> sk->pacing_rate = 2 * cwnd * mss / rtt
>
> It works well for senders (bulk flows), but not very well for receivers
> or even RPC :
>
> cwnd on the receiver can be less than 10, rtt can be around 100ms, so we
> can end up pacing ACK packets, slowing down the sender.
>
> Really, only the sender should pace, according to its own logic.
>
> Instead of adding a new bit in skb, or call yet another flow
> dissection, we tweak skb->truesize to a small value (2), and
> we instruct sch_fq to use new helper and not pace pure ack.
>
> Note this also helps TCP small queue, as ack packets present
> in qdisc/NIC do not prevent sending a data packet (RPC workload)
>
> This helps to reduce tx completion overhead, ack packets can use regular
> sock_wfree() instead of tcp_wfree() which is a bit more expensive.
>
> This has no impact in the case packets are sent to loopback interface,
> as we do not coalesce ack packets (were we would detect skb->truesize
> lie)
>
> In case netem (with a delay) is used, skb_orphan_partial() also sets
> skb->truesize to 1.
>
> This patch is a combination of two patches we used for about one year at
> Google.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [RFC PATCH 00/29] net: VRF support
From: roopa @ 2015-02-05 5:17 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, ebiederm, hannes
In-Reply-To: <1423100070-31848-1-git-send-email-dsahern@gmail.com>
On 2/4/15, 5:34 PM, David Ahern wrote:
> Kernel patches are also available here:
> https://github.com/dsahern/linux.git vrf-3.19
>
> iproute2 patches are also available here:
> https://github.com/dsahern/iproute2 vrf-3.19
>
>
> Background
> ----------
> The concept of VRFs (Virtual Routing and Forwarding) has been around for over
> 15 years. Support for VRFs in the Linux kernel has been an often requested
> feature for almost as long. For a while support was available via an out of
> tree patch [1]. Since network namespaces came along, the response to queries
> about VRF support for Linux was 'use namespaces'. But as mentioned previously
> [2] network namespaces are not a good match for VRFs. Of the list of problems
> noted the big one is that namespaces do not scale efficiently to the number
> of VRFs supported by networking gear (> 1000 VRFs). Networking vendors that
> want to use Linux as the OS have to carry custom solutions to this problem --
> be it userspace networking stacks, extensive kernel patches (to add VRF
> support or bend the implementation of namespaces), and/or patches to many
> open source components. The recent addition of switchdev support in the
> kernel suggests that people expect the use of Linux as a switch networking
> OS to increase. Hopefully the time is right to re-open the discussion on a
> salable VRF implementation for the Linux kernel.
yes, We have been thinking vrfs and have stumbled upon similar questions
and problems you list.
Thanks for the work and putting up a proposal. Haven't looked at all of
your patches in detail, but
we are certainly interested in working on a possible vrf solution for Linux.
>
> The intent of this RFC is to get feedback on the overall idea - namely VRFs
> as integer id and the nesting of VRFs within a namespace. This set includes
> changes only to core IPv4 code which shows the concept; changes to the rest
> of the network stack are fairly repetitive.
I see that the changes look many but they are mostly adding the vrf
indirection.
We have been looking at ip rules (for the use cases with non-duplicate
ip addresses) and also
at net namespaces. Currently net namespaces seems like a good solution
but it provides
stricter isolation than needed and we will need to punch holes or leak
stuff across namespaces
to make all use cases of vrfs really work.
Your approach seems reasonable so far.
more on this later,
Thanks!
>
> This patch set has a number of similarities to the original VRF patch - most
> notably VRF ids as an integer index and plumbing through iproute2 and
> netlink. But this set is really a complete re-implementation of the feature,
> integrating VRF within a namespace and leveraging existing support for
> network namespaces.
>
> Design
> ------
> Namespaces provide excellent separation of the networking stack from the
> netdevices and up. The intent of VRFs is to provide an additional,
> logical separation at the L3 layer within a namespace.
>
> +----------------------------------------------------------+
> | Namespace foo |
> | +---------------+ |
> | +------+ | L3/L4 service | |
> | | lldp | | (VRF any) | |
> | +------+ +---------------+ |
> | |
> | +-------------------------+ |
> | | VRF M | |
> | +---------------------+ +-------------------------+ | |
> | | VRF 1 (default) | | VRF N | | |
> | | +---------------+ | | +---------------+ | | |
> | | | L3/L4 service | | | | L3/L4 service | | | |
> | | | (VRF unaware) | | | | (VRF unaware) | | | |
> | | +---------------+ | | +---------------+ | | |
> | | | | | | |
> | |+-----+ +----------+ | | +-----+ +----------+ | | |
> | || FIB | | neighbor | | | | FIB | | neighbor | | | |
> | |+-----+ +----------+ | | +-----+ +----------+ | | |
> | | | | |-+ |
> | | {dev 1} {dev 2} | | {dev 3} {dev 4} {dev 5} | |
> | +---------------------+ +-------------------------+ |
> +----------------------------------------------------------+
>
> This is accomplished by enhancing the current namespace checks to a
> broader network context that is both a namepsace and a VRF id. The VRF
> id is a tag applied to relevant structures, an integer between 1 and 4095
> which allows for 4095 VRFs (could have 0 be the default VRF and then the
> range is 0-4095 = 4096s VRFs). (The limitation is arguably artificial. It
> is based on the genid scheme for versioning networking data which is a
> 32-bit integer. The VRF id is the lower 12 bits of the genid's.)
>
> Netdevices, sk_buffs, sockets, and tasks are all tagged with a VRF id.
> Network lookups (devices, sockets, addresses, routes, neighbors) require a
> match of both network namespace and VRF id (or the special 'vrf any' tag;
> more on that later).
>
> Beyond the 4-byte tag in various data structures, there are no resources
> allocated to a VRF so there is no need to create or destroy a VRF which is
> in-line with the concept of keeping it lightweight for scalability. The
> trade-off is that VRFs use the the same sysctl settings as the namespace
> they are part of and, for example, MIB counters.
>
> The VRF id of tasks defaults to 1 and is inherited parent to child. It can
> be read via the file '/proc/<pid>/vrf' and can be changed anytime by writing
> to this file (if preferred this can be made a prctl to change the VRF id).
> This allows services to be launched in a VRF context using ip, similar to
> what is done for network namespaces.
> e.g., ip vrf exec 99 /usr/sbin/sshd
>
> (or a simpler chvrf alias/command can be used to just write the VRF id
> to the proc file.)
>
> The task's VRF id also affects viewing and modifying network configuration.
> For example, 'ip addr show', 'ip route ls', 'ifconfig', 'arp -n', etc, only
> show network data for the VRF associated with the task's VRF id; devices
> are at the L2 layer so a command listing devices is not impacted by VRF id.
>
> When a socket is created the VRF id is taken from the task. Socket-vrf
> association for non-connected sockets can be changed using a setsockopt
> (e.g., create a socket then change VRF id prior to calling bind or connect).
>
> Network devices belong to a single VRF context which defaults to VRF 1.
> They can be assigned to another VRF using IFLA_VRF attribute in link
> messages. Similarly the VRF assignment is returned in the IFLA_VRF
> attribute. The ip command has been modified to display the VRF id of a
> device. L2 applications like lldp are not VRF aware and still work through
> through all network devices within the namespace.
>
> On RX skbs get their VRF context from the netdevice the packet is received
> on. For TX the VRF context for an skb is taken from the socket. The
> intention is for L3/raw sockets to be able to set the VRF context for a
> packet TX using cmsg (not coded in this patch set).
>
> VRF aware apps (e.g., L3 VPNs) can have sockets in multiple VRFs for
> forwarding packets.
>
> The special 'ANY VRF' context allows a single instance of a daemon to
> provide a service across all VRFs.
> e.g., ip vrf exec any /usr/sbin/sshd
>
> The 'any' context applies to listen sockets only; connected sockets are in
> a VRF context. Child sockets accepted by the daemon acquire the VRF context
> of the network device the connection originated on.
>
> The 'ANY VRF' context can also be used to display all addresses, routes
> or neighbors in the kernel cache. That is, 'ip addr show', 'ip route ls',
> 'ifconfig', 'arp -n', etc, show all network data for the namespace.
>
>
> About this Patch Set
> --------------------
> This is not a complete conversion of the networking stack, only a small
> sampling to test the waters. Only changes are to core IPv4 code [2] which
> is sufficient to illustrate the fundamental concept. Changes from
> struct net to net_ctx are very repetitive.
>
> I'm sure there are a lot of oversights and bugs, but the intent here is
> to solicit feedback on the overall idea.
>
>
> Examples
> --------
> To illustrate the VRF patches consider a system with 18 NICs:
> - eth0, eth17 are in default namespace (e.g., management namespace)
>
> - eth1 - eth8 are in group1 namespace
> - eth1 - eth4 are in VRF 11
> - eth5 - eth8 are in VRF 13
>
> - eth9 - eth16 are in group2 namespace
> - eth9 - eth12 are in VRF 21
> - eth13 - eth16 are in VRF 23
>
> - Addresses assigned to each interface:
> - eth1: 1.1.1.1/24
> - eth2: 2.2.2.1/24
> - eth3: 3.3.3.1/24
> - eth4: 4.4.4.1/24
> - eth5: 1.1.1.1/24 (not a typo, duplicate address in different vrfs)
> - eth6: 6.6.6.1/24
> - eth7: 7.7.7.1/24
> - eth8: 8.8.8.1/24
>
> - openlldpd is started in each namespace
>
> 1. device list is VRF agnostic
> - ifconfig -a, ip link show, /proc/net/dev
> --> default namespace shows only eth0 and eth17
> --> group1 namespace shows only eth1 - eth8
> --> group2 namespace shows only eth9 - eth16
> - ip shows vrf assignment of each link
>
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 vrf 11 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
> link/ether 02:ab:cd:02:00:01 brd ff:ff:ff:ff:ff:ff
>
> 2. address, route, neighbor list is VRF aware
> - ifconfig, ip addr show, ip route ls, /proc/net/route
> --> shows only addresses for VRF id of task unless id is 'any'
>
> in VRF 1:
> ifconfig eth1
> eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> ether 02:ab:cd:02:00:01 txqueuelen 1000 (Ethernet)
> ...
>
> No addresses are shown. But if the command is run in VRF 11 or VRF 'any'
> ip vrf exec 11 ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 vrf 11 qdisc pfifo_fast state UP group default qlen 1000
> link/ether 02:ab:cd:02:00:01 brd ff:ff:ff:ff:ff:ff
> inet 1.1.1.1/24 brd 1.1.1.255 scope global eth1
> valid_lft forever preferred_lft forever
>
> 3. start ssh in group1 namespace
> ip netns exec group1 ip vrf exec 11 /usr/sbin/sshd -d
> ssh to 1.1.1.1 via eth1
>
> ip netns exec group1 ip vrf exec 13 /usr/sbin/sshd -d
> ssh to 1.1.1.1 via eth5
> --> same namespace but different VRFs
>
> 4. One ssh instance handles VRFs in group1 namespace
> ip netns exec group1 ip vrf exec any /usr/sbin/sshd
>
> --> ssh to any address in the namespace works
>
> References
> ----------
> [1] http://sourceforge.net/projects/linux-vrf
>
> [2] http://www.spinics.net/lists/netdev/msg298368.html
>
> [3] To build only enable core ipv4 code. Disable IPv6, netfilter, ipsec, etc.
>
>
> David Ahern (29):
> net: Introduce net_ctx and macro for context comparison
> net: Flip net_device to use net_ctx
> net: Flip sock_common to net_ctx
> net: Add net_ctx macros for skbuffs
> net: Flip seq_net_private to net_ctx
> net: Flip fib_rules and fib_rules_ops to use net_ctx
> net: Flip inet_bind_bucket to net_ctx
> net: Flip fib_info to net_ctx
> net: Flip ip6_flowlabel to net_ctx
> net: Flip neigh structs to net_ctx
> net: Flip nl_info to net_ctx
> net: Add device lookups by net_ctx
> net: Convert function arg from struct net to struct net_ctx
> net: vrf: Introduce vrf header file
> net: vrf: Add vrf to net_ctx struct
> net: vrf: Set default vrf
> net: vrf: Add vrf context to task struct
> net: vrf: Plumbing for vrf context on a socket
> net: vrf: Add vrf context to skb
> net: vrf: Add vrf context to flow struct
> net: vrf: Add vrf context to genid's
> net: vrf: Set VRF id in various network structs
> net: vrf: Enable vrf checks
> net: vrf: Add support to get/set vrf context on a device
> net: vrf: Handle VRF any context
> net: vrf: Change single_open_net to pass net_ctx
> net: vrf: Add vrf checks and context to ipv4 proc files
> iproute2: vrf: Add vrf subcommand
> iproute2: Add vrf option to ip link command
>
> fs/proc/base.c | 94 +++++++++++++++++++++++++
> fs/proc/proc_net.c | 22 +++++-
> include/linux/inetdevice.h | 12 ++--
> include/linux/init_task.h | 1 +
> include/linux/netdevice.h | 44 +++++++++++-
> include/linux/sched.h | 2 +
> include/linux/seq_file_net.h | 10 +--
> include/linux/skbuff.h | 5 ++
> include/net/addrconf.h | 22 +++---
> include/net/arp.h | 2 +-
> include/net/dst.h | 16 ++---
> include/net/fib_rules.h | 10 ++-
> include/net/flow.h | 10 ++-
> include/net/inet6_hashtables.h | 19 +++---
> include/net/inet_hashtables.h | 60 ++++++++++------
> include/net/inet_sock.h | 1 +
> include/net/inet_timewait_sock.h | 1 +
> include/net/ip.h | 10 +--
> include/net/ip6_fib.h | 4 +-
> include/net/ip6_route.h | 24 +++----
> include/net/ip_fib.h | 38 +++++++----
> include/net/ipv6.h | 14 +++-
> include/net/neighbour.h | 93 +++++++++++++++++++++----
> include/net/net_namespace.h | 39 +++++++++--
> include/net/netlink.h | 5 +-
> include/net/route.h | 46 +++++++------
> include/net/sock.h | 21 ++++--
> include/net/tcp.h | 1 +
> include/net/transp_v6.h | 2 +-
> include/net/udp.h | 8 +--
> include/net/vrf.h | 36 ++++++++++
> include/net/xfrm.h | 28 ++++----
> include/uapi/linux/if_link.h | 1 +
> include/uapi/linux/in.h | 1 +
> kernel/fork.c | 2 +
> net/core/dev.c | 95 +++++++++++++++++++++++---
> net/core/fib_rules.c | 36 ++++++----
> net/core/flow.c | 5 +-
> net/core/neighbour.c | 106 +++++++++++++++--------------
> net/core/rtnetlink.c | 12 ++++
> net/core/skbuff.c | 12 ++++
> net/core/sock.c | 2 +
> net/ipv4/af_inet.c | 20 ++++--
> net/ipv4/arp.c | 76 ++++++++++++---------
> net/ipv4/datagram.c | 6 +-
> net/ipv4/devinet.c | 64 ++++++++++++------
> net/ipv4/fib_frontend.c | 83 ++++++++++++++---------
> net/ipv4/fib_rules.c | 12 ++--
> net/ipv4/fib_semantics.c | 38 +++++++----
> net/ipv4/fib_trie.c | 24 +++++--
> net/ipv4/icmp.c | 40 ++++++-----
> net/ipv4/igmp.c | 53 +++++++++------
> net/ipv4/inet_connection_sock.c | 23 ++++---
> net/ipv4/inet_diag.c | 13 ++--
> net/ipv4/inet_hashtables.c | 42 +++++++-----
> net/ipv4/inet_timewait_sock.c | 1 +
> net/ipv4/ip_input.c | 6 +-
> net/ipv4/ip_options.c | 20 +++---
> net/ipv4/ip_output.c | 16 +++--
> net/ipv4/ip_sockglue.c | 32 +++++++--
> net/ipv4/ipconfig.c | 6 +-
> net/ipv4/ipmr.c | 53 +++++++++------
> net/ipv4/netfilter.c | 13 ++--
> net/ipv4/ping.c | 41 +++++------
> net/ipv4/proc.c | 10 +--
> net/ipv4/raw.c | 48 ++++++++-----
> net/ipv4/route.c | 143 +++++++++++++++++++++++----------------
> net/ipv4/syncookies.c | 6 +-
> net/ipv4/tcp_ipv4.c | 57 +++++++++-------
> net/ipv4/tcp_minisocks.c | 1 +
> net/ipv4/udp.c | 122 ++++++++++++++++++---------------
> net/ipv4/udp_diag.c | 11 +--
> net/ipv4/xfrm4_policy.c | 14 ++--
> net/netlink/af_netlink.c | 12 ++++
> net/sctp/protocol.c | 10 +--
> net/xfrm/xfrm_policy.c | 9 +--
> 76 files changed, 1415 insertions(+), 682 deletions(-)
> create mode 100644 include/net/vrf.h
>
^ permalink raw reply
* Re: [PATCH v2 net-next] pkt_sched: fq: better control of DDOS traffic
From: Eric Dumazet @ 2015-02-05 5:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20150204.202245.1889006308590918014.davem@davemloft.net>
On Wed, 2015-02-04 at 20:22 -0800, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 03 Feb 2015 09:32:19 -0800
>
> > + if (tb[TCA_FQ_ORPHAN_MASK])
> > + q->orphan_mask = nla_get_u32(tb[TCA_FQ_ORPHAN_MASK]);
>
> This doesn't build, the header file changes that add TCA_FQ_ORPHAN_MASK
> are missing from your patch.
Arg.. sorry for that. Will send a v3
^ permalink raw reply
* [PATCH v3 net-next] pkt_sched: fq: better control of DDOS traffic
From: Eric Dumazet @ 2015-02-05 5:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1422984739.907.25.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
FQ has a fast path for skb attached to a socket, as it does not
have to compute a flow hash. But for other packets, FQ being non
stochastic means that hosts exposed to random Internet traffic
can allocate million of flows structure (104 bytes each) pretty
easily. Not only host can OOM, but lookup in RB trees can take
too much cpu and memory resources.
This patch adds a new attribute, orphan_mask, that is adding
possibility of having a stochastic hash for orphaned skb.
Its default value is 1024 slots, to mimic SFQ behavior.
Note: This does not apply to locally generated TCP traffic,
and no locally generated traffic will share a flow structure
with another perfect or stochastic flow.
This patch also handles the specific case of SYNACK messages:
They are attached to the listener socket, and therefore all map
to a single hash bucket. If listener have set SO_MAX_PACING_RATE,
hoping to have new accepted socket inherit this rate, SYNACK
might be paced and even dropped.
This is very similar to an internal patch Google have used more
than one year.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
v3: adding the missing include file change
v2: make the left shift in fq_classify.
include/uapi/linux/pkt_sched.h | 2 ++
net/sched/sch_fq.c | 19 +++++++++++++++++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/pkt_sched.h b/include/uapi/linux/pkt_sched.h
index d62316baae942c43b2558ed2768c88950516126c..534b847107453019d362e9f9f9c0969fc3100c8b 100644
--- a/include/uapi/linux/pkt_sched.h
+++ b/include/uapi/linux/pkt_sched.h
@@ -774,6 +774,8 @@ enum {
TCA_FQ_FLOW_REFILL_DELAY, /* flow credit refill delay in usec */
+ TCA_FQ_ORPHAN_MASK, /* mask applied to orphaned skb hashes */
+
__TCA_FQ_MAX
};
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index 69a3dbf55c60271723e580b209282c8b3ae91ae8..a00c4304300101a093e834c73fdd3bdb2c2c38a3 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -93,6 +93,7 @@ struct fq_sched_data {
u32 flow_refill_delay;
u32 flow_max_rate; /* optional max rate per flow */
u32 flow_plimit; /* max packets per flow */
+ u32 orphan_mask; /* mask for orphaned skb */
struct rb_root *fq_root;
u8 rate_enable;
u8 fq_trees_log;
@@ -223,11 +224,20 @@ static struct fq_flow *fq_classify(struct sk_buff *skb, struct fq_sched_data *q)
if (unlikely((skb->priority & TC_PRIO_MAX) == TC_PRIO_CONTROL))
return &q->internal;
- if (unlikely(!sk)) {
+ /* SYNACK messages are attached to a listener socket.
+ * 1) They are not part of a 'flow' yet
+ * 2) We do not want to rate limit them (eg SYNFLOOD attack),
+ * especially if the listener set SO_MAX_PACING_RATE
+ * 3) We pretend they are orphaned
+ */
+ if (!sk || sk->sk_state == TCP_LISTEN) {
+ unsigned long hash = skb_get_hash(skb) & q->orphan_mask;
+
/* By forcing low order bit to 1, we make sure to not
* collide with a local flow (socket pointers are word aligned)
*/
- sk = (struct sock *)(skb_get_hash(skb) | 1L);
+ sk = (struct sock *)((hash << 1) | 1UL);
+ skb_orphan(skb);
}
root = &q->fq_root[hash_32((u32)(long)sk, q->fq_trees_log)];
@@ -704,6 +714,9 @@ static int fq_change(struct Qdisc *sch, struct nlattr *opt)
q->flow_refill_delay = usecs_to_jiffies(usecs_delay);
}
+ if (tb[TCA_FQ_ORPHAN_MASK])
+ q->orphan_mask = nla_get_u32(tb[TCA_FQ_ORPHAN_MASK]);
+
if (!err) {
sch_tree_unlock(sch);
err = fq_resize(sch, fq_log);
@@ -749,6 +762,7 @@ static int fq_init(struct Qdisc *sch, struct nlattr *opt)
q->delayed = RB_ROOT;
q->fq_root = NULL;
q->fq_trees_log = ilog2(1024);
+ q->orphan_mask = 1024 - 1;
qdisc_watchdog_init(&q->watchdog, sch);
if (opt)
@@ -778,6 +792,7 @@ static int fq_dump(struct Qdisc *sch, struct sk_buff *skb)
nla_put_u32(skb, TCA_FQ_FLOW_MAX_RATE, q->flow_max_rate) ||
nla_put_u32(skb, TCA_FQ_FLOW_REFILL_DELAY,
jiffies_to_usecs(q->flow_refill_delay)) ||
+ nla_put_u32(skb, TCA_FQ_ORPHAN_MASK, q->orphan_mask) ||
nla_put_u32(skb, TCA_FQ_BUCKETS_LOG, q->fq_trees_log))
goto nla_put_failure;
^ permalink raw reply related
* [PATCH] af_packet: don't pass empty blocks for PACKET_V3
From: Alexander Drozdov @ 2015-02-05 5:58 UTC (permalink / raw)
To: David S. Miller
Cc: Daniel Borkmann, Eric Dumazet, Al Viro, Willem de Bruijn,
Michael S. Tsirkin, netdev, linux-kernel, Alexander Drozdov
Don't close an empty block on timeout. Its meaningless to
pass it to the user. Moreover, passing empty blocks wastes
CPU & buffer space increasing probability of packets
dropping on small timeouts.
Side effect of this patch is indefinite user-space wait
in poll on idle links. But, I believe its better to set
timeout for poll(2) when needed than to get empty blocks
every millisecond when not needed.
Signed-off-by: Alexander Drozdov <al.drozdov@gmail.com>
---
net/packet/af_packet.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 9cfe2e1..9a2f70a 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -698,6 +698,10 @@ static void prb_retire_rx_blk_timer_expired(unsigned long data)
if (pkc->last_kactive_blk_num == pkc->kactive_blk_num) {
if (!frozen) {
+ if (!BLOCK_NUM_PKTS(pbd)) {
+ /* An empty block. Just refresh the timer. */
+ goto refresh_timer;
+ }
prb_retire_current_block(pkc, po, TP_STATUS_BLK_TMO);
if (!prb_dispatch_next_block(pkc, po))
goto refresh_timer;
@@ -798,7 +802,11 @@ static void prb_close_block(struct tpacket_kbdq_core *pkc1,
h1->ts_last_pkt.ts_sec = last_pkt->tp_sec;
h1->ts_last_pkt.ts_nsec = last_pkt->tp_nsec;
} else {
- /* Ok, we tmo'd - so get the current time */
+ /* Ok, we tmo'd - so get the current time.
+ *
+ * It shouldn't really happen as we don't close empty
+ * blocks. See prb_retire_rx_blk_timer_expired().
+ */
struct timespec ts;
getnstimeofday(&ts);
h1->ts_last_pkt.ts_sec = ts.tv_sec;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode
From: Hiroshi Shimamoto @ 2015-02-05 6:10 UTC (permalink / raw)
To: Jeff Kirsher
Cc: e1000-devel@lists.sourceforge.net, Choi, Sy Jong,
linux-kernel@vger.kernel.org, David Laight, Hayato Momma,
netdev@vger.kernel.org, Bjørn Mork
In-Reply-To: <1423054641.2589.59.camel@jtkirshe-mobl>
> Subject: Re: [E1000-devel] [PATCH 1/3] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode
>
> On Fri, 2015-01-30 at 11:37 +0000, Hiroshi Shimamoto wrote:
> > From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
> >
> > The limitation of the number of multicast address for VF is not enough
> > for the large scale server with SR-IOV feature.
> > IPv6 requires the multicast MAC address for each IP address to handle
> > the Neighbor Solicitation message.
> > We couldn't assign over 30 IPv6 addresses to a single VF interface.
> >
> > The easy way to solve this is enabling multicast promiscuous mode.
> > It is good to have a functionality to enable multicast promiscuous
> > mode
> > for each VF from VF driver.
> >
> > This patch introduces the new mbox API, IXGBE_VF_SET_MC_PROMISC, to
> > enable/disable multicast promiscuous mode in VF. If multicast
> > promiscuous
> > mode is enabled the VF can receive all multicast packets.
> >
> > With this patch, the ixgbevf driver automatically enable multicast
> > promiscuous mode when the number of multicast addresses is over than
> > 30
> > if possible.
> >
> > This also bump the API version up to 1.2 to check whether the API,
> > IXGBE_VF_SET_MC_PROMISC is available.
> >
> > Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
> > Reviewed-by: Hayato Momma <h-momma@ce.jp.nec.com>
> > CC: Choi, Sy Jong <sy.jong.choi@intel.com>
> > ---
> > drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
> > drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 4 +
> > drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 89
> > ++++++++++++++++++++++-
> > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 13 +++-
> > drivers/net/ethernet/intel/ixgbevf/mbx.h | 4 +
> > drivers/net/ethernet/intel/ixgbevf/vf.c | 29 +++++++-
> > drivers/net/ethernet/intel/ixgbevf/vf.h | 1 +
> > 7 files changed, 137 insertions(+), 4 deletions(-)
>
> Hiroshi, I tried to apply your patches to my queue but they do not apply
> cleanly and they are in a DOS file format, not UNIX. I also noted
> several checkpatch.pl issues with your patches, so please fix those up
> as well.
I'm sorry to bother you.
Will fix.
>
> Can you please fix up your patches based on my tree:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/queue.git
Yes. I haven't noticed your tree.
Will resend patches against it.
thanks,
Hiroshi
>
> This my queue of all community patches against the Intel LAN drivers and
> will be where I queue up your patches while they are under review and
> testing.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH v3 net-next] pkt_sched: fq: better control of DDOS traffic
From: David Miller @ 2015-02-05 6:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1423114240.31870.33.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 04 Feb 2015 21:30:40 -0800
> This patch adds a new attribute, orphan_mask, that is adding
> possibility of having a stochastic hash for orphaned skb.
...
> v3: adding the missing include file change
> v2: make the left shift in fq_classify.
Applied, thanks Eric.
^ permalink raw reply
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Michal Kazior @ 2015-02-05 6:46 UTC (permalink / raw)
To: Eric Dumazet
Cc: Neal Cardwell, linux-wireless, Network Development,
eyalpe-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb
In-Reply-To: <1423084303.31870.15.camel-XN9IlZ5yJG9HTL0Zs8A6p/gx64E7kk8eUsxypvmhUTTZJqsBc5GL+g@public.gmane.org>
On 4 February 2015 at 22:11, Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I do not see how a TSO patch could hurt a flow not using TSO/GSO.
>
> This makes no sense.
>
> ath10k tx completions being batched/deferred to a tasklet might increase
> probability to hit this condition in tcp_wfree() :
>
> /* If this softirq is serviced by ksoftirqd, we are likely under stress.
> * Wait until our queues (qdisc + devices) are drained.
> * This gives :
> * - less callbacks to tcp_write_xmit(), reducing stress (batches)
> * - chance for incoming ACK (processed by another cpu maybe)
> * to migrate this flow (skb->ooo_okay will be eventually set)
> */
> if (wmem >= SKB_TRUESIZE(1) && this_cpu_ksoftirqd() == current)
> goto out;
>
> Meaning tcp stack waits all skbs left qdisc/NIC queues before queuing
> additional packets.
>
> I would try to call skb_orphan() in ath10k if you really want to keep
> these batches.
>
> I have hard time to understand why tx completed packets go through
> ath10k_htc_rx_completion_handler().. anyway...
There's a couple of layers for host-firmware communication. The
transport layer (e.g. PCI) delivers HTC packets. These contain WMI
(configuration stuff) or HTT (traffic stuff). HTT can contain
different events (tx complete, rx complete, etc). HTT Tx completion
contains a list of ids which refer to frames that have been completed
(either sent or dropped).
I've tried reverting tx/rx tasklet batching. No change in throughput.
I can get tcpdump if you're interested.
> Most conservative patch would be :
>
> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
> index 9c782a42665e1aaf43bfbca441631ee58da50c09..6a36317d6bb0447202dee15528130bd5e21248c4 100644
> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
> @@ -1642,6 +1642,7 @@ void ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
> break;
> }
> case HTT_T2H_MSG_TYPE_TX_COMPL_IND:
> + skb_orphan(skb);
> spin_lock_bh(&htt->tx_lock);
> __skb_queue_tail(&htt->tx_compl_q, skb);
> spin_unlock_bh(&htt->tx_lock);
I suppose you want to call skb_orphan() on actual data packets, right?
This skb is just a host-firmware communication buffer.
Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* How to increase wifi A-MDU with lots of streaming peers?
From: Ben Greear @ 2015-02-05 7:03 UTC (permalink / raw)
To: netdev, linux-wireless@vger.kernel.org
Suppose one has an AP that is trying to support 40 or so clients all streaming
video, using http gets to get around 2 seconds worth of data at a time.
The AP's NIC is ath10k, stations are a mix of /n and /ac.
User has control of streaming server and AP, but not clients.
I think from wifi transport side, it would be best if data could be
excessively queued in the wifi AP so that larger A-MPDUs could possibly
be sent. The streaming server could use large tcp tx socket buffers to
deal with extra latency that the AP's queueing would cause.
First, does this seem sane.
And second, any idea how to go about it?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-next] bridge: Let bridge not age 'externally' learnt FDB entries, they are removed when 'external' entity notifies the aging
From: Scott Feldman @ 2015-02-05 7:13 UTC (permalink / raw)
To: roopa; +Cc: Siva Mannem, Netdev, Scott Feldman, Jiri Pirko
In-Reply-To: <54D246A7.2020502@cumulusnetworks.com>
On Wed, Feb 4, 2015 at 8:19 AM, roopa <roopa@cumulusnetworks.com> wrote:
> On 2/4/15, 12:02 AM, Siva Mannem wrote:
>>
>> On Tue, Feb 3, 2015 at 8:41 PM, roopa <roopa@cumulusnetworks.com> wrote:
>>>
>>> On 2/2/15, 9:21 AM, Siva Mannem wrote:
>>>>
>>>> When 'learned_sync' flag is turned on, the offloaded switch
>>>> port syncs learned MAC addresses to bridge's FDB via switchdev
>>>> notifier
>>>> (NETDEV_SWITCH_FDB_ADD). Currently, FDB entries learnt via this
>>>> mechanism are
>>>> wrongly being deleted by bridge aging logic. This patch ensures that
>>>> FDB
>>>> entries synced from offloaded switch ports are not deleted by
>>>> bridging
>>>> logic.
>>>> Such entries can only be deleted via switchdev notifier
>>>> (NETDEV_SWITCH_FDB_DEL).
>>>
>>>
>>> Your patch seems right and maintains symmetry for fdb add/del of
>>> externally
>>> learnt entries.
>>> However, this could be made configurable. I think some drivers may rely
>>> on
>>> bridge driver aging these entries (The default setting needs more
>>> thought).
>>> I am not sure what rocker does (CC'ed rocker maintainers). But, our
>>> driver
>>> does rely on the bridge driver aging these entries by default.
>>
>> added_by_external_learn flag is only set for entries learned via
>> switchdev notifier
>> (NETDEV_SWITCH_FDB_ADD) and rocker is the only driver using these
>> notifiers.
>> I see that rocker is deleting the entries via switchdev notifier
>> (NETDEV_SWITCH_FDB_DEL).
>> This mechanism is only used by drivers when learned_sync is turned on by
>> user.
>>
>> $ sudo bridge link set dev swp1 learning_sync on self
>>
>> Am I missing something here?
>
> I know that its enabled by an external flag. I wasn't sure rocker was doing
> a del
> or was relying on the bridge driver to age those entries (hence the CC to
> rocker maintainers).
> And, my only point was its valid in some cases for the switch driver to rely
> on bridge driver ageing those entries.
> For symmetry, your patch seems right.
No, not right. Drats, email was sent to the wrong address for me.
Thanks Roopa for trying to keep me in the loop.
We want the bridge's aging logic to age out these externally learned
entries, just like it would age out internally learned entries.
I'd like to see this patch reverted so we can have a more
comprehensive discussion/solution. With this patch applied, the only
user (rocker) of NETDEV_SWITCH_FDB_ADD is broken. So please undo this
patch so rocker isn't broken and let's work on a knob to suit both
modes: 1) let bridge manage aging, 2) let device manage aging.
-scott
^ permalink raw reply
* [PATCH 1/1] neighbour: Support broadcast ARP in neighbor PROPE state
From: zhuyj @ 2015-02-05 7:20 UTC (permalink / raw)
To: netdev, stefan.costandache, alexandre.dietsch, yue.tao,
clinton.slabbert
Cc: eulfsam, David S. Miller, WANG Cong, zhuyj
From: eulfsam <ulf.samuelsson@ericsson.com>
When the neighbor statemachine is in PROBE state, it will normally send
a number of unicast ARP requests (number defined in "ucast_probes" entry
in the proc file system, default=3) and if no reply is received, it will
change state to FAILED.
Enabling CONFIG_ARP_PROBE_BCAST, will make the statemachine try to send
broadcast ARP requests, and only enter FAILED state if the broadcast ARP
requests did not receive a reply.
Enabling CONFIG_ARP_PROBE_BCAST, makes the IPv4 ARP behaviour more
similar to the IPv6 Neighbor Discovery protocol, and is neccessary,
if the other end only responds to broadcast ARPs.
CC: David S. Miller <davem@davemloft.net>
CC: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: eulfsam <ulf.samuelsson@ericsson.com>
Signed-off-by: zhuyj <zyjzyj2000@gmail.com>
---
net/core/neighbour.c | 4 ++++
net/ipv4/Kconfig | 17 +++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 8d614c9..50f5ee2 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -830,10 +830,14 @@ out:
static __inline__ int neigh_max_probes(struct neighbour *n)
{
struct neigh_parms *p = n->parms;
+#ifdef CONFIG_ARP_PROBE_BCAST
+ return p->ucast_probes + p->app_probes + p->mcast_probes;
+#else
int max_probes = NEIGH_VAR(p, UCAST_PROBES) + NEIGH_VAR(p, APP_PROBES);
if (!(n->nud_state & NUD_PROBE))
max_probes += NEIGH_VAR(p, MCAST_PROBES);
return max_probes;
+#endif
}
static void neigh_invalidate(struct neighbour *neigh)
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index bd29016..4d13edb 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -259,6 +259,23 @@ config IP_PIMSM_V2
gated-5). This routing protocol is not used widely, so say N unless
you want to play with it.
+config ARP_PROBE_BCAST
+ bool "IP: ARP send broadcast ARP, if probing using unicast fails"
+ default y
+ ---help---
+ When the neighbor statemachine is in PROBE state, it will
+ normally send a number of unicast ARP requests
+ (number defined in "ucast_probes" entry in the proc file system, default=3)
+ and if no reply is received, it will change state to FAILED.
+
+ Saying Y here, will make the statemachine try to send broadcast ARP
+ requests, and only enter FAILED state if the broadcast ARP requests did not
+ receive a reply.
+
+ Enabling this, makes the IPv4 ARP behaviour more similar to the IPv6
+ Neighbor Discovery protocol, and is neccessary, if the other end
+ only responds to broadcast ARPs.
+
config SYN_COOKIES
bool "IP: TCP syncookie support"
---help---
--
1.9.1
^ permalink raw reply related
* Re: Question: should local address be expired when updating PMTU?
From: Steffen Klassert @ 2015-02-05 7:21 UTC (permalink / raw)
To: shengyong; +Cc: davem, netdev, yangyingliang, hannes
In-Reply-To: <54D17D1A.3020706@huawei.com>
On Wed, Feb 04, 2015 at 09:59:54AM +0800, shengyong wrote:
>
> Sorry, the later. I test it on 3.10-stable. It can fix this problem. So maybe this is a bug?
Yes, it's a bug.
> And the 3 approaches (different flags are used: RTF_LOCAL, IFF_LOOPBACK and RTF_CACHE) in
> these mails can fix the expire of local address. I'm confused about these flags:
> * RTF_LOCAL: the entries of local address, like address binded to the native NIC
> * RTF_CACHE: all cached entries
> * IFF_LOOPBACK: this is a device-related flag, which has the same meaning as RTF_LOCAL
>
> Am I right? If so, I think RTF_LOCAL is appropriate, because we just want entries of local
> addresses to be not expired and we don't care other entries (I think if they get expired,
> a neigh discovery could find them back).
It is not the address that expires, it is the learned PMTU value that
expires. If we delete an uncached route, nothing will bring it back
unless you readd it manually.
We need to ensure that all routes that can learn something what
expires are cached. This means that we clone the inserted route
when it is used for the first time. The learned values are stored
at this cloned route. If the learned value expires, the clone is
deleted. The original route remains in the fib tree and can be
still looked up.
The problem is, that we currently don't cache/clone host routes.
So if a host route learns something that expires, the original
route is removed from the fib tree and we loose connectivity
to that host. We don't cache host routes because some of them
(the local ones) are automatically added with metric 0.
If we try to cache such a route, the clone will be identical
to the original route and we fail to insert it to the fib tree.
So we need to adjust the caching to all routes that actually can
learn something and leave out only those that can not.
I'll send a patchset that should fix this at the beginning of the
next week.
^ permalink raw reply
* crash when setting ovs instance over net-next
From: Or Gerlitz @ 2015-02-05 7:32 UTC (permalink / raw)
To: Pravin Shelar, Jesse Gross; +Cc: netdev@vger.kernel.org
With latest net-next (commit 06eb395 "pkt_sched: fq: better control of
DDOS traffic")
under the below config [2], I see this crash [1], will send you also my
.config
The user-space bits are openvswitch-2.0.90-1 rpm built from the git.
Or.
[1] crash
general protection fault: 0000 [#1] SMP
Modules linked in: vport_vxlan openvswitch crc32c_generic libcrc32c
rdma_ucm rdma_cm iw_cm ib_ipoib ib_cm ib_uverbs ib_umad mlx4_en mlx4_ib
vxlan udp_tunnel ip6_udp_tunnel ib_sa ib_mad ib_core ib_addr ipv6
mlx4_core dm_mirror dm_region_hash dm_log dm_mod igb ptp pps_core sg
joydev microcode ehci_pci ehci_hcd pcspkr rng_core ioatdma dca shpchp
button sr_mod ext3 jbd floppy usb_storage sd_mod ata_generic ata_piix
libata scsi_mod uhci_hcd radeon ttm drm_kms_helper hwmon
CPU: 1 PID: 2818 Comm: upcall_2 Tainted: G I
3.19.0-rc6-net-next+ #457
Hardware name: Supermicro X7DWU/X7DWU, BIOS 1.1 04/30/2008
task: ffff8802244d1000 ti: ffff880213de8000 task.ti: ffff880213de8000
RIP: 0010:[<ffffffff8111df0e>] [<ffffffff8111df0e>] kfree+0xac/0x196
RSP: 0018:ffff880213deb998 EFLAGS: 00010207
RAX: ffffea0000000000 RBX: 5709530001977006 RCX: 0000000000000028
RDX: 0000000000000001 RSI: 0000000000000000 RDI: 5709530001977006
RBP: ffff880213deb9c8 R08: 0000000000000000 R09: 0000000000000000
R10: ffff880213deb9d8 R11: 0000000000000000 R12: 015c112c00065dc0
R13: ffffffffa060bd87 R14: ffff880223f12240 R15: ffff880215038288
FS: 00007fb5ed7b5700(0000) GS:ffff88022fc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000465e40 CR3: 0000000213273000 CR4: 00000000000007e0
Stack:
ffff88022485e800 ffff880215038220 ffff880215038220 ffff88022485e800
ffff880223f12240 ffff880215038288 ffff880213deb9e8 ffffffffa060bd87
ffff880215038220 ffff880215194800 ffff880213deb9f8 ffffffffa060bde0
Call Trace:
[<ffffffffa060bd87>] flow_free+0x21/0x59 [openvswitch]
[<ffffffffa060bde0>] ovs_flow_free+0x21/0x23 [openvswitch]
[<ffffffffa0605b4a>] ovs_packet_cmd_execute+0x2f3/0x35f [openvswitch]
[<ffffffffa0605995>] ? ovs_packet_cmd_execute+0x13e/0x35f [openvswitch]
[<ffffffff811fe6fb>] ? nla_parse+0x4f/0xec
[<ffffffff8139a2fc>] genl_family_rcv_msg+0x26d/0x2c9
[<ffffffff8107620f>] ? __lock_acquire+0x90e/0x9aa
[<ffffffff8139a3be>] genl_rcv_msg+0x66/0x89
[<ffffffff8139a358>] ? genl_family_rcv_msg+0x2c9/0x2c9
[<ffffffff81399591>] netlink_rcv_skb+0x3e/0x95
[<ffffffff81399898>] ? genl_rcv+0x18/0x37
[<ffffffff813998a7>] genl_rcv+0x27/0x37
[<ffffffff81399033>] netlink_unicast+0x103/0x191
[<ffffffff81399382>] netlink_sendmsg+0x2c1/0x310
[<ffffffff811007ad>] ? might_fault+0x50/0xa0
[<ffffffff8135c773>] do_sock_sendmsg+0x5f/0x7a
[<ffffffff8135c799>] sock_sendmsg+0xb/0xd
[<ffffffff8135cacf>] ___sys_sendmsg+0x1a3/0x218
[<ffffffff8113e54b>] ? get_close_on_exec+0x86/0x86
[<ffffffff8115a9d0>] ? fsnotify+0x32c/0x348
[<ffffffff8115a720>] ? fsnotify+0x7c/0x348
[<ffffffff8113e5f5>] ? __fget+0xaa/0xbf
[<ffffffff8113e54b>] ? get_close_on_exec+0x86/0x86
[<ffffffff8135cccd>] __sys_sendmsg+0x3d/0x5e
[<ffffffff8135cd02>] SyS_sendmsg+0x14/0x16
[<ffffffff81411852>] system_call_fastpath+0x12/0x17
Code: b8 00 00 00 80 ff 77 00 00 eb 07 48 8b 05 1b 81 8f 00 4e 8d 24 20
48 b8 00 00 00 00 00 ea ff ff 49 c1 ec 0c 49 c1 e4 06 49 01 c4 <49> 8b
04 24 66 85 c0 79 10 49 8b 44 24 30 49 8b 14 24 66 85 d2
RIP [<ffffffff8111df0e>] kfree+0xac/0x196
RSP <ffff880213deb998>
---[ end trace 7f18bf585a5b229c ]---
[2] config
$ ovs-vsctl show
0ea2d6c6-93d0-4e5d-ad99-d47213bb0bf1
Bridge ovs-tun
Port "vxlan0"
Interface "vxlan0"
type: vxlan
options: {dst_port="4789", key="98",
remote_ip="192.168.31.18"}
Port ovs-tun
Interface ovs-tun
type: internal
Port "veth3"
Interface "veth3"
Port "veth1"
Interface "veth1"
ovs_version: "2.0.90"
^ permalink raw reply
* Re: [PATCH net-next] bridge: Let bridge not age 'externally' learnt FDB entries, they are removed when 'external' entity notifies the aging
From: David Miller @ 2015-02-05 7:53 UTC (permalink / raw)
To: sfeldma; +Cc: roopa, siva.mannem.lnx, netdev, sfeldma, jiri
In-Reply-To: <CAE4R7bCASKHmZD+tiu=ZWM9dzvTrSLsaXxgtOYLpsmOR87kcTQ@mail.gmail.com>
From: Scott Feldman <sfeldma@gmail.com>
Date: Wed, 4 Feb 2015 23:13:07 -0800
> I'd like to see this patch reverted so we can have a more
> comprehensive discussion/solution. With this patch applied, the only
> user (rocker) of NETDEV_SWITCH_FDB_ADD is broken. So please undo this
> patch so rocker isn't broken and let's work on a knob to suit both
> modes: 1) let bridge manage aging, 2) let device manage aging.
Patch reverted.
^ permalink raw reply
* Re: [PATCHv2 net-next] cxgb4: Add low latency socket busy_poll support
From: David Miller @ 2015-02-05 7:56 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, anish, nirranjan, kumaras
In-Reply-To: <1423044172-23586-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Wed, 4 Feb 2015 15:32:52 +0530
> cxgb_busy_poll, corresponding to ndo_busy_poll, gets called by the socket
> waiting for data.
>
> With busy_poll enabled, improvement is seen in latency numbers as observed by
> collecting netperf TCP_RR numbers.
> Below are latency number, with and without busy-poll, in a switched environment
> for a particular msg size:
> netperf command: netperf -4 -H <ip> -l 30 -t TCP_RR -- -r1,1
> Latency without busy-poll: ~16.25 us
> Latency with busy-poll : ~08.79 us
>
> Based on original work by Kumar Sanghvi <kumaras@chelsio.com>
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
> ---
> V2: fix napi poll return value for repoll, thanks to pointers by
> Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* [patch] net: sxgbe: fix error handling in init_rx_ring()
From: Dan Carpenter @ 2015-02-05 8:00 UTC (permalink / raw)
To: Byungho An, kgene; +Cc: Girish K S, Vipul Pandya, netdev, kernel-janitors
In-Reply-To: <20150116071229.GH5520@mwanda>
There are a couple bugs with the error handling in this function.
1) If we can't allocate "rx_ring->rx_skbuff" then we should call
dma_free_coherent() but we don't.
2) free_rx_ring() frees "rx_ring->rx_skbuff_dma" and "rx_ring->rx_skbuff"
so calling it in a loop causes a double free.
Also it was a bit confusing how we sometimes freed things before doing
the goto. I've cleaned it up so it does error handling in normal kernel
style.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index 11288d4..c8a01ee 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -364,6 +364,26 @@ static int sxgbe_init_rx_buffers(struct net_device *dev,
return 0;
}
+
+/**
+ * sxgbe_free_rx_buffers - free what sxgbe_init_rx_buffers() allocated
+ * @dev: net device structure
+ * @rx_ring: ring to be freed
+ * @rx_rsize: ring size
+ * Description: this function initializes the DMA RX descriptor
+ */
+static void sxgbe_free_rx_buffers(struct net_device *dev,
+ struct sxgbe_rx_norm_desc *p, int i,
+ unsigned int dma_buf_sz,
+ struct sxgbe_rx_queue *rx_ring)
+{
+ struct sxgbe_priv_data *priv = netdev_priv(dev);
+
+ kfree_skb(rx_ring->rx_skbuff[i]);
+ dma_unmap_single(priv->device, rx_ring->rx_skbuff_dma[i],
+ dma_buf_sz, DMA_FROM_DEVICE);
+}
+
/**
* init_tx_ring - init the TX descriptor ring
* @dev: net device structure
@@ -456,7 +476,7 @@ static int init_rx_ring(struct net_device *dev, u8 queue_no,
/* RX ring is not allcoated */
if (rx_ring == NULL) {
netdev_err(dev, "No memory for RX queue\n");
- goto error;
+ return -ENOMEM;
}
/* assign queue number */
@@ -468,23 +488,21 @@ static int init_rx_ring(struct net_device *dev, u8 queue_no,
&rx_ring->dma_rx_phy, GFP_KERNEL);
if (rx_ring->dma_rx == NULL)
- goto error;
+ return -ENOMEM;
/* allocate memory for RX skbuff array */
rx_ring->rx_skbuff_dma = kmalloc_array(rx_rsize,
sizeof(dma_addr_t), GFP_KERNEL);
if (!rx_ring->rx_skbuff_dma) {
- dma_free_coherent(priv->device,
- rx_rsize * sizeof(struct sxgbe_rx_norm_desc),
- rx_ring->dma_rx, rx_ring->dma_rx_phy);
- goto error;
+ ret = -ENOMEM;
+ goto err_free_dma_rx;
}
rx_ring->rx_skbuff = kmalloc_array(rx_rsize,
sizeof(struct sk_buff *), GFP_KERNEL);
if (!rx_ring->rx_skbuff) {
- kfree(rx_ring->rx_skbuff_dma);
- goto error;
+ ret = -ENOMEM;
+ goto err_free_skbuff_dma;
}
/* initialise the buffers */
@@ -494,7 +512,7 @@ static int init_rx_ring(struct net_device *dev, u8 queue_no,
ret = sxgbe_init_rx_buffers(dev, p, desc_index,
bfsize, rx_ring);
if (ret)
- goto err_init_rx_buffers;
+ goto err_free_rx_buffers;
}
/* initalise counters */
@@ -504,11 +522,22 @@ static int init_rx_ring(struct net_device *dev, u8 queue_no,
return 0;
-err_init_rx_buffers:
- while (--desc_index >= 0)
- free_rx_ring(priv->device, rx_ring, desc_index);
-error:
- return -ENOMEM;
+err_free_rx_buffers:
+ while (--desc_index >= 0) {
+ struct sxgbe_rx_norm_desc *p;
+
+ p = rx_ring->dma_rx + desc_index;
+ sxgbe_free_rx_buffers(dev, p, desc_index, bfsize, rx_ring);
+ }
+ kfree(rx_ring->rx_skbuff);
+err_free_skbuff_dma:
+ kfree(rx_ring->rx_skbuff_dma);
+err_free_dma_rx:
+ dma_free_coherent(priv->device,
+ rx_rsize * sizeof(struct sxgbe_rx_norm_desc),
+ rx_ring->dma_rx, rx_ring->dma_rx_phy);
+
+ return ret;
}
/**
* free_tx_ring - free the TX descriptor ring
^ permalink raw reply related
* Re: [PATCH] cxgb4: Delete an unnecessary check before the function call "release_firmware"
From: David Miller @ 2015-02-05 8:07 UTC (permalink / raw)
To: elfring; +Cc: hariprasad, netdev, linux-kernel, kernel-janitors, julia.lawall
In-Reply-To: <54D1F6AF.2090408@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 04 Feb 2015 11:38:39 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 4 Feb 2015 11:28:43 +0100
>
> The release_firmware() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Applied.
^ permalink raw reply
* Re: [PATCH net 1/1] qlcnic: Fix NAPI poll routine for Tx completion
From: David Miller @ 2015-02-05 8:24 UTC (permalink / raw)
To: shahed.shaikh; +Cc: netdev, Dept-GELinuxNICDev
In-Reply-To: <1423046485-9526-1-git-send-email-shahed.shaikh@qlogic.com>
From: Shahed Shaikh <shahed.shaikh@qlogic.com>
Date: Wed, 4 Feb 2015 05:41:25 -0500
> From: Shahed Shaikh <shahed.shaikh@qlogic.com>
>
> After d75b1ade567f ("net: less interrupt masking in NAPI")
> driver's NAPI poll routine is expected to return
> exact budget value if it wants to be re-called.
>
> Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
> Fixes: d75b1ade567f ("net: less interrupt masking in NAPI")
Applied, thanks.
^ 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