* Re: [net-next 0/5][pull request] 1GbE Intel Wired LAN Driver Updates 2016-09-22
From: Jeff Kirsher @ 2016-09-28 1:50 UTC (permalink / raw)
To: davem; +Cc: netdev, nhorman, sassmann, jogreene, guru.anbalagane, bhelgaas
In-Reply-To: <1474612741-75681-1-git-send-email-jeffrey.t.kirsher@intel.com>
[-- Attachment #1: Type: text/plain, Size: 746 bytes --]
On Thu, 2016-09-22 at 23:38 -0700, Jeff Kirsher wrote:
> This series contains updates to igb, igbvf and PCI quirks.
>
> Wei Yongjun makes a function static to shut up sparse.
>
> Todd bumps the igb and igbvf version, which is long overdue.
>
> Jake fixes an issue where the PPS SYS_WRAP interrupt was not re-enabled
> after a reset, which resulted in disabling of the PPS signaling.
>
> Sasha adds a quirk for 82579 devices, which was reported by Red Hat.
> The issue is that 82579 has a problem reattaching itself after being
> detached, so disable the FLR capability in PCIe configuration space.
Based on feedback, I will drop patch 5 in the series and re-submit the
series, while Alex and Sasha re-work the PCI quirk patch.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v4 net-next] tcp: Change txhash on every SYN and RTO retransmit
From: Lawrence Brakmo @ 2016-09-28 2:03 UTC (permalink / raw)
To: netdev; +Cc: Kernel Team, Eric Dumazet, Yuchung Cheng, Neal Cardwell
The current code changes txhash (flowlables) on every retransmitted
SYN/ACK, but only after the 2nd retransmitted SYN and only after
tcp_retries1 RTO retransmits.
With this patch:
1) txhash is changed with every SYN retransmits
2) txhash is changed with every RTO.
The result is that we can start re-routing around failed (or very
congested paths) as soon as possible. Otherwise application health
checks may fail and the connection may be terminated before we start
to change txhash.
v4: Removed sysctl, txhash is changed for all RTOs
v3: Removed text saying default value of sysctl is 0 (it is 100)
v2: Added sysctl documentation and cleaned code
Tested with packetdrill tests
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
---
net/ipv4/tcp_timer.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index f712b41..3ea1cf8 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -192,6 +192,8 @@ static int tcp_write_timeout(struct sock *sk)
if (tp->syn_data && icsk->icsk_retransmits == 1)
NET_INC_STATS(sock_net(sk),
LINUX_MIB_TCPFASTOPENACTIVEFAIL);
+ } else if (!tp->syn_data && !tp->syn_fastopen) {
+ sk_rethink_txhash(sk);
}
retry_until = icsk->icsk_syn_retries ? : net->ipv4.sysctl_tcp_syn_retries;
syn_set = true;
@@ -213,6 +215,8 @@ static int tcp_write_timeout(struct sock *sk)
tcp_mtu_probing(icsk, sk);
dst_negative_advice(sk);
+ } else {
+ sk_rethink_txhash(sk);
}
retry_until = net->ipv4.sysctl_tcp_retries2;
--
2.9.3
^ permalink raw reply related
* [net-next v2 1/4] igb: fix non static symbol warning
From: Jeff Kirsher @ 2016-09-28 2:04 UTC (permalink / raw)
To: davem
Cc: Wei Yongjun, netdev, nhorman, sassmann, jogreene, guru.anbalagane,
Jeff Kirsher
In-Reply-To: <1475028301-122700-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Fixes the following sparse warning:
drivers/net/ethernet/intel/igb/igb_ethtool.c:2707:5: warning:
symbol 'igb_rxnfc_write_vlan_prio_filter' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 0c33eca..737b664 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -2704,8 +2704,8 @@ static int igb_rxnfc_write_etype_filter(struct igb_adapter *adapter,
return 0;
}
-int igb_rxnfc_write_vlan_prio_filter(struct igb_adapter *adapter,
- struct igb_nfc_filter *input)
+static int igb_rxnfc_write_vlan_prio_filter(struct igb_adapter *adapter,
+ struct igb_nfc_filter *input)
{
struct e1000_hw *hw = &adapter->hw;
u8 vlan_priority;
--
2.7.4
^ permalink raw reply related
* [net-next v2 0/4][pull request] 1GbE Intel Wired LAN Driver Updates 2016-09-27
From: Jeff Kirsher @ 2016-09-28 2:04 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene,
guru.anbalagane
This series contains updates to igb and igbvf.
Wei Yongjun makes a function static to shut up sparse.
Todd bumps the igb and igbvf version, which is long overdue.
Jake fixes an issue where the PPS SYS_WRAP interrupt was not re-enabled
after a reset, which resulted in disabling of the PPS signaling.
v2: dropped patch 5 of the original series, since the PCI quirk patch
needs to be reworked by Alex and Sasha to address issues that Bjorn
Helgaas and Alex Williamson brought up.
The following are changes since commit e96e0eded1335b9cfac71fcdd989d682eb3f8412:
bnx2x: free the mac filter group list before freeing the cmd
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 1GbE
Jacob Keller (1):
igb: restore PPS signal on igb_ptp_reset
Todd Fujinaka (2):
igbvf: bump version to igbvf-2.4.0
igb: bump version to igb-5.4.0
Wei Yongjun (1):
igb: fix non static symbol warning
drivers/net/ethernet/intel/igb/igb.h | 1 +
drivers/net/ethernet/intel/igb/igb_ethtool.c | 4 ++--
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/ethernet/intel/igb/igb_ptp.c | 5 ++++-
drivers/net/ethernet/intel/igbvf/netdev.c | 2 +-
5 files changed, 9 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply
* [net-next v2 2/4] igbvf: bump version to igbvf-2.4.0
From: Jeff Kirsher @ 2016-09-28 2:04 UTC (permalink / raw)
To: davem
Cc: Todd Fujinaka, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1475028301-122700-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Todd Fujinaka <todd.fujinaka@intel.com>
Bump version to match other igbvf drivers.
Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igbvf/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index b0778ba..12bb877 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -47,7 +47,7 @@
#include "igbvf.h"
-#define DRV_VERSION "2.0.2-k"
+#define DRV_VERSION "2.4.0-k"
char igbvf_driver_name[] = "igbvf";
const char igbvf_driver_version[] = DRV_VERSION;
static const char igbvf_driver_string[] =
--
2.7.4
^ permalink raw reply related
* [net-next v2 4/4] igb: restore PPS signal on igb_ptp_reset
From: Jeff Kirsher @ 2016-09-28 2:05 UTC (permalink / raw)
To: davem
Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1475028301-122700-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
When a reset occurs, the PPS SYS_WRAP interrupt was not re-enabled which
resulted in disabling of the PPS signaling. Fix this by recording when
the interrupt is on and ensuring that we re-enable it every time we
reset.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb.h | 1 +
drivers/net/ethernet/intel/igb/igb_ptp.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index 03fbe4b..d11093d 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -489,6 +489,7 @@ struct igb_adapter {
struct timecounter tc;
u32 tx_hwtstamp_timeouts;
u32 rx_hwtstamp_cleared;
+ bool pps_sys_wrap_on;
struct ptp_pin_desc sdp_config[IGB_N_SDP];
struct {
diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c b/drivers/net/ethernet/intel/igb/igb_ptp.c
index 1dd14e1..a7895c4 100644
--- a/drivers/net/ethernet/intel/igb/igb_ptp.c
+++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
@@ -591,6 +591,7 @@ static int igb_ptp_feature_enable_i210(struct ptp_clock_info *ptp,
tsim |= TSINTR_SYS_WRAP;
else
tsim &= ~TSINTR_SYS_WRAP;
+ igb->pps_sys_wrap_on = !!on;
wr32(E1000_TSIM, tsim);
spin_unlock_irqrestore(&igb->tmreg_lock, flags);
return 0;
@@ -1235,7 +1236,9 @@ void igb_ptp_reset(struct igb_adapter *adapter)
case e1000_i211:
wr32(E1000_TSAUXC, 0x0);
wr32(E1000_TSSDP, 0x0);
- wr32(E1000_TSIM, TSYNC_INTERRUPTS);
+ wr32(E1000_TSIM,
+ TSYNC_INTERRUPTS |
+ (adapter->pps_sys_wrap_on ? TSINTR_SYS_WRAP : 0));
wr32(E1000_IMS, E1000_IMS_TS);
break;
default:
--
2.7.4
^ permalink raw reply related
* [net-next v2 3/4] igb: bump version to igb-5.4.0
From: Jeff Kirsher @ 2016-09-28 2:05 UTC (permalink / raw)
To: davem
Cc: Todd Fujinaka, netdev, nhorman, sassmann, jogreene,
guru.anbalagane, Jeff Kirsher
In-Reply-To: <1475028301-122700-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Todd Fujinaka <todd.fujinaka@intel.com>
Bump igb version to match other igb drivers.
Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index a83aa13..edc9a6a 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -58,7 +58,7 @@
#include "igb.h"
#define MAJ 5
-#define MIN 3
+#define MIN 4
#define BUILD 0
#define DRV_VERSION __stringify(MAJ) "." __stringify(MIN) "." \
__stringify(BUILD) "-k"
--
2.7.4
^ permalink raw reply related
* Re: kernel BUG at net/unix/garbage.c:149!"
From: David Miller @ 2016-09-28 2:05 UTC (permalink / raw)
To: kernel; +Cc: mszeredi, hannes, linux-kernel, netdev
In-Reply-To: <57EA7F3B.3030801@kyup.com>
From: Nikolay Borisov <kernel@kyup.com>
Date: Tue, 27 Sep 2016 17:16:27 +0300
> What's the status of https://patchwork.ozlabs.org/patch/664062/ , is
> this going to be picked up ?
Why would I apply a patch that's an RFC, doesn't have a proper commit
message, lacks a proper signoff, and also lacks ACK's and feedback
from other knowledgable developers?
^ permalink raw reply
* Re: [PATCH trival -resend 1/2] bpf: clean up put_cpu_var usage
From: David Miller @ 2016-09-28 2:10 UTC (permalink / raw)
To: shli; +Cc: linux-kernel, netdev, akpm, tj, ast
In-Reply-To: <7ffd1960225e024a738e4c372f091bb49096e294.1474990741.git.shli@fb.com>
From: Shaohua Li <shli@fb.com>
Date: Tue, 27 Sep 2016 08:42:41 -0700
> put_cpu_var takes the percpu data, not the data returned from
> get_cpu_var.
>
> This doesn't change the behavior.
>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: Shaohua Li <shli@fb.com>
Applied.
^ permalink raw reply
* Re: [PATCH trival -resend 2/2] lib: clean up put_cpu_var usage
From: David Miller @ 2016-09-28 2:10 UTC (permalink / raw)
To: shli; +Cc: linux-kernel, netdev, akpm, tj
In-Reply-To: <935eea817a8d13d9223e09b4ca11e0508aee8437.1474990741.git.shli@fb.com>
From: Shaohua Li <shli@fb.com>
Date: Tue, 27 Sep 2016 08:42:42 -0700
> put_cpu_var takes the percpu data, not the data returned from
> get_cpu_var.
>
> This doesn't change the behavior.
>
> Cc: Tejun Heo <tj@kernel.org>
> Signed-off-by: Shaohua Li <shli@fb.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.
From: David Miller @ 2016-09-28 2:12 UTC (permalink / raw)
To: chris.roth; +Cc: linux-usb, netdev, linux-kernel, allan
In-Reply-To: <ff932915b6fc47489095c2ad7fa6ede5@Mail08.usask.ca>
From: <chris.roth@usask.ca>
Date: Tue, 27 Sep 2016 09:57:50 -0600
> From: Chris Roth <chris.roth@usask.ca>
>
> From Allan Chou <allan@asix.com.tw>
> From: Chris Roth <chris.roth@usask.ca>
Three From lines, it's actually quite amazing how you were
able to achieve this.
Please take some time, and carefully craft your patch emails but don't
send them to the list.
Instead, email yourself, and look at what you receive.
Do not post this patch to the list until the test emails you send to
yourself look correct.
Thank you.
^ permalink raw reply
* Re: Explaining RX-stages for XDP
From: Alexei Starovoitov via iovisor-dev @ 2016-09-28 2:12 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Eric Dumazet, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iovisor-dev-9jONkmmOlFHEE9lA1F8Ukti2O/JbrIOy@public.gmane.org,
John Fastabend, Jamal Hadi Salim, David Miller, Saeed Mahameed,
Tom Herbert, Daniel Borkmann, Pablo Neira Ayuso
In-Reply-To: <20160927113237.7138c097-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, Sep 27, 2016 at 11:32:37AM +0200, Jesper Dangaard Brouer wrote:
>
> Let me try in a calm way (not like [1]) to explain how I imagine that
> the XDP processing RX-stage should be implemented. As I've pointed out
> before[2], I'm proposing splitting up the driver into RX-stages. This
> is a mental-model change, I hope you can follow my "inception" attempt.
>
> The basic concept behind this idea is, if the RX-ring contains
> multiple "ready" packets, then the kernel was too slow, processing
> incoming packets. Thus, switch into more efficient mode, which is a
> "packet-vector" mode.
>
> Today, our XDP micro-benchmarks looks amazing, and they are! But once
> real-life intermixed traffic is used, then we loose the XDP I-cache
> benefit. XDP is meant for DoS protection, and an attacker can easily
> construct intermixed traffic. Why not fix this architecturally?
>
> Most importantly concept: If XDP return XDP_PASS, do NOT pass the
> packet up the network stack immediately (that would flush I-cache).
> Instead store the packet for the next RX-stage. Basically splitting
> the packet-vector into two packet-vectors, one for network-stack and
> one for XDP. Thus, intermixed XDP vs. netstack not longer have effect
> on XDP performance.
>
> The reason for also creating an XDP packet-vector, is to move the
> XDP_TX transmit code out of the XDP processing stage (and future
> features). This maximize I-cache availability to the eBPF program,
> and make eBPF performance more uniform across drivers.
>
>
> Inception:
> * Instead of individual packets, see it as a RX packet-vector.
> * XDP should be seen as a stage *before* the network stack gets called.
>
> If your mind can handle it: I'm NOT proposing a RX-vector of 64-packets.
> I actually want N-packet per vector (8-16). As the NIC HW RX process
> runs concurrently, and by the time it takes to process N-packets, more
> packets have had a chance to arrive in the RX-ring queue.
Sounds like what Edward was proposing earlier with building
link list of skbs and passing further into stack?
Or the idea is different ?
As far as intermixed XDP vs stack traffic, I think for DoS case the traffic
patterns are binary. Either all of it is good or under attack most of
the traffic is bad, so makes sense to optimize for these two.
50/50 case I think is artificial and not worth optimizing for.
For all good traffic whether xdp is there or not shouldn't matter
for this N-vector optimization. Whether it's a batch of 8, 16 or 64,
either via link-list or array, it should probably be a generic
mechanism independent of any xdp stuff.
For under attack traffic the most important is to optimize for line
rate parsing of the traffic inside bpf and quickest as possible
drop on the driver side. Few good packets that are passed to the stack
make no difference to overall system performance.
I think existing mlx4+xdp is already optimized for 'mostly attack' traffic
and performs pretty weel, since imo 'all drop' benchmark is accurate.
Optimizing xdp for 'mostly good' traffic is indeed a challange.
We'd need all the tricks to make it as good as normal skb-based traffic.
I haven't seen any tests yet comparing xdp with 'return XDP_PASS' program
vs no xdp at all running netperf tcp/udp in user space. It shouldn't
be too far off. Doing this benchmarking on mlx4 is also not necessarily
will speak for ixgbe, since large mtu there is packet per page already,
so whenever ixgbe supports xdp, I think, ixgbe+xdp+'return XDP_PASS'
should be the same tcp/udp performance as ixgbe+large_mtu.
No doubt, would be interesting to see mlx numbers.
^ permalink raw reply
* Re: [RFC 0/3] ipsec: flow cache removal
From: David Miller @ 2016-09-28 2:15 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1474992323-11327-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Tue, 27 Sep 2016 18:05:20 +0200
> Please do not apply these patches.
To be honest, I really want to :-)
> These are part of tests I made for the ipsec workshop at upcoming
> netdev 1.2 and I wanted to post these before the conference.
>
> Short version is that there appear to be no major scalability issues
> anymore without flow cache. Performance hit can be up to 30%
> in my tests (with 64 byte packets), however without flow cache we
> also avoid some undesirable effects when flow cache is constantly
> overloaded.
>
> Seems most of the extra cost is mainly because of extra xfrm dst
> init/destruction (and not e.g. due to policy lookup).
Yes, if you have to allocate/destroy a dst every lookup then
it will hurt a lot. Perhaps we can have a pre-cooked dst hung
off of some existing object as a first level strategy to avoid
this.
> Lets discuss more at the workshop.
Indeed.
^ permalink raw reply
* Re: [PATCH V2 net-next 15/15] smc: proc-fs interface for smc connections
From: David Miller @ 2016-09-28 2:27 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, utz.bacher
In-Reply-To: <20160927164156.26184-16-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Tue, 27 Sep 2016 18:41:56 +0200
> Maintain a list of SMC sockets and display important SMC socket
> information in /proc/net/smc.
>
> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
Dumping internal tables and information via /procfs is strongly
deprecated.
Please use a more modern mechanism (such as netlink) to expose this
information to the user.
You'll be most likely to succeed in your submission if you make use of
or design a generic facility that allows other drivers similar to
your's to provide this kind of information as well.
I'm sorry if this is frustrating, but this is a huge piece of
infrastructure, therefore you can expect lots of pieces to get
feedback and require changes like this.
^ permalink raw reply
* Re: [PATCH v2] netfilter: xt_hashlimit: Fix link error in 32bit arch because of 64bit division
From: Maciej Żenczykowski @ 2016-09-28 2:32 UTC (permalink / raw)
To: Vishwanath Pai
Cc: Pablo Neira Ayuso, johunt, netfilter-devel, coreteam,
Linux NetDev, pai.vishwain, kaber, kadlec, zlpnobody,
Hannes Frederic Sowa, Eric Dumazet
In-Reply-To: <20160927135718.GA31297@akamai.com>
I don't think you actually need the backslashes since this ain't in a
MACRO definition context.
^ permalink raw reply
* Re: [PATCH RFC net-next] bnx2x: avoid printing unnecessary messages during register dump
From: David Miller @ 2016-09-28 2:43 UTC (permalink / raw)
To: gpiccoli; +Cc: ariel.elior, Yuval.Mintz, netdev
In-Reply-To: <1475001234-25933-1-git-send-email-gpiccoli@linux.vnet.ibm.com>
From: "Guilherme G. Piccoli" <gpiccoli@linux.vnet.ibm.com>
Date: Tue, 27 Sep 2016 15:33:54 -0300
> The bnx2x driver prints multiple error messages during register dump,
> with "ethtool -d" for example. The driver even warn that many messages
> might be seen during the register dump, but they are harmless. A typical
> kernel log after register dump looks like this:
>
> [9.375] bnx2x: [bnx2x_get_regs:987(net0)]Generating register dump. Might trigger harmless GRC timeouts
> [9.439] bnx2x: [bnx2x_attn_int_deasserted3:4342(net0)]LATCHED attention 0x04000000 (masked)
> [9.439] bnx2x: [bnx2x_attn_int_deasserted3:4346(net0)]GRC time-out 0x010580cd
> [...]
>
> The notation [...] means that some messages were supressed - in our
> tests we saw 78 more "LATCHED attention" and "GRC time-out" messages,
> supressed here.
>
> This patch avoid these messages to be printed on register dump instead
> of just warn they are harmless.
>
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Although "ethtool -d" is really a debugging facility, I still think that
serious care should be placed into arranging what gets dumped in such
a way that such access timeouts and errors are minimized.
^ permalink raw reply
* Re: [PATCH nf-next v2 1/2] netfilter: Fix potential null pointer dereference
From: Liping Zhang @ 2016-09-28 3:08 UTC (permalink / raw)
To: Feng Gao
Cc: Aaron Conole, Netfilter Developer Mailing List,
Linux Kernel Network Developers, Florian Westphal,
Pablo Neira Ayuso
In-Reply-To: <CA+6hz4q_Fjc7mVZq7RG+RnioXFnD0w8Ows0AqwEy-5CJ7zg0yQ@mail.gmail.com>
Hi Feng,
2016-09-28 9:23 GMT+08:00 Feng Gao <gfree.wind@gmail.com>:
> Hi Aaraon,
>
> On Tue, Sep 27, 2016 at 9:38 PM, Aaron Conole <aconole@bytheb.org> wrote:
>> It's possible for nf_hook_entry_head to return NULL if two
>> nf_unregister_net_hook calls happen simultaneously with a single hook
>
> The critical region of nf_unregister_net_hook is protected by &nf_hook_mutex.
> When it would be called simultaneously?
This is unrelated to race condition.
Suppose that only the last nf_hook_entry exist, and two callers want to do
un-register work.
The first one will remove it successfully, after the end of the work, the
second one will enter the critical section, but it will see the NULL pointer.
Because the last nf_hook_entry was already removed by the first one.
>
> Regards
> Feng
>
>> entry in the list. This fix ensures that no null pointer dereference
>> could occur when such a race happens.
>>
>> Signed-off-by: Aaron Conole <aconole@bytheb.org>
^ permalink raw reply
* Re: [PATCH nf-next v2 1/2] netfilter: Fix potential null pointer dereference
From: Liping Zhang @ 2016-09-28 3:13 UTC (permalink / raw)
To: Feng Gao
Cc: Aaron Conole, Netfilter Developer Mailing List,
Linux Kernel Network Developers, Florian Westphal,
Pablo Neira Ayuso
In-Reply-To: <CAML_gOeTZhaWXffe0UqXRP_e=-+1vCs_z9ynrG7XJeUnmOs-6A@mail.gmail.com>
2016-09-28 11:08 GMT+08:00 Liping Zhang <zlpnobody@gmail.com>:
> Hi Feng,
>
> 2016-09-28 9:23 GMT+08:00 Feng Gao <gfree.wind@gmail.com>:
>> Hi Aaraon,
>>
>> On Tue, Sep 27, 2016 at 9:38 PM, Aaron Conole <aconole@bytheb.org> wrote:
>>> It's possible for nf_hook_entry_head to return NULL if two
>>> nf_unregister_net_hook calls happen simultaneously with a single hook
>>
>> The critical region of nf_unregister_net_hook is protected by &nf_hook_mutex.
>> When it would be called simultaneously?
>
> This is unrelated to race condition.
>
> Suppose that only the last nf_hook_entry exist, and two callers want to do
> un-register work.
>
> The first one will remove it successfully, after the end of the work, the
> second one will enter the critical section, but it will see the NULL pointer.
> Because the last nf_hook_entry was already removed by the first one.
>
>>
>> Regards
>> Feng
>>
>>> entry in the list. This fix ensures that no null pointer dereference
>>> could occur when such a race happens.
>>>
>>> Signed-off-by: Aaron Conole <aconole@bytheb.org>
I read the commit log again, I think the description here is a
little confusing indeed.
^ permalink raw reply
* Re: [net-next v2 0/4][pull request] 1GbE Intel Wired LAN Driver Updates 2016-09-27
From: David Miller @ 2016-09-28 3:22 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, guru.anbalagane
In-Reply-To: <1475028301-122700-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 27 Sep 2016 19:04:57 -0700
> This series contains updates to igb and igbvf.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH v3 net-next] tcp: Change txhash on every SYN and RTO retransmit
From: Lawrence Brakmo @ 2016-09-28 5:07 UTC (permalink / raw)
To: Neal Cardwell, Yuchung Cheng; +Cc: netdev, Kernel Team, Eric Dumazet
In-Reply-To: <CADVnQykozyJ3nnHz956aXnT9c+cEqUmf0HMqSHjbKQXWiMoSTA@mail.gmail.com>
Neal and Yuchung, thank you for the feedback. I¹ve submitted v4 with your
recommended changes.
Thanks,
Larry
On 9/27/16, 6:28 PM, "Neal Cardwell" <ncardwell@google.com> wrote:
>On Tue, Sep 27, 2016 at 8:18 PM, Yuchung Cheng <ycheng@google.com> wrote:
>> On Tue, Sep 27, 2016 at 4:31 PM, Lawrence Brakmo <brakmo@fb.com> wrote:
>>> @@ -213,6 +215,8 @@ static int tcp_write_timeout(struct sock *sk)
>>> tcp_mtu_probing(icsk, sk);
>>>
>>> dst_negative_advice(sk);
>>> + } else if (prandom_u32_max(100) <
>>>sysctl_tcp_rto_txhash_prob) {
>> The sysctl is not really needed but that's just my opinion.
>
>I agree that it sounds nice to simplify by not having a sysctl for
>this and always calling sk_rethink_txhash() here.
>
>neal
^ permalink raw reply
* Re: [PATCH RFC 1/3] net: Add dev_set_env_hdr_len to accept envelope frames
From: Toshiaki Makita @ 2016-09-28 6:09 UTC (permalink / raw)
To: Mintz, Yuval, netdev@vger.kernel.org, Patrick McHardy,
Stephen Hemminger, Vlad Yasevich, Jeff Kirsher
In-Reply-To: <BL2PR07MB2306030D4912AD8F574BAF9D8DCC0@BL2PR07MB2306.namprd07.prod.outlook.com>
On 2016/09/27 23:23, Mintz, Yuval wrote:
>> +/* return envelope header length */
>> +static inline int netif_get_env_hdr_len(struct net_device *dev) {
>> + if (dev->netdev_ops->ndo_set_env_hdr_len)
>> + return dev->env_hdr_len;
>> +
>> + if (netif_reduces_vlan_mtu(dev))
>> + return 0;
>> +
>> + return 4; /* VLAN_HLEN */
>> +}
>
Thank you for taking a look at this.
> Why claim that `4' is the default?
> What's the benefit of propagating this value to userspace if
> driver doesn't actually support it?
I'm sorry, this is a leftover from previous draft when I was not aware
of type 2-2 drivers (that do not allow over-MTU-sized packets other than
vlan-tagged ones). Now I'm thinking we should not include
IFLA_ENV_HDR_LEN in response of GETLINK if it is not supported.
I'll delete current logic from next version.
>
> Assuming this *is* a good default [meaning your analysis indicated
> basically every driver has at least so many octets reserved]
> perhaps we should consider initializing the env_hdr_len in some
> common function [e.g., in setup_ether() next to the mtu] to this value?
I actually tried it first and realized it is difficult, since so many
drivers use their own initializer instead of ether_setup(). Anyway, I'm
going not to expose envhdrlen when it is not supported.
Thanks,
Toshiaki Makita
^ permalink raw reply
* [PATCH v5 1/7] net:snmp: Introduce generic interfaces for snmp_get_cpu_field{,64}
From: Jia He @ 2016-09-28 6:22 UTC (permalink / raw)
To: netdev
Cc: linux-sctp, linux-kernel, davem, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Vlad Yasevich, Neil Horman,
Steffen Klassert, Herbert Xu, marcelo.leitner, Jia He
In-Reply-To: <1475043748-18161-1-git-send-email-hejianet@gmail.com>
This is to introduce the generic interfaces for snmp_get_cpu_field{,64}.
It exchanges the two for-loops for collecting the percpu statistics data.
This can aggregate the data by going through all the items of each cpu
sequentially.
Signed-off-by: Jia He <hejianet@gmail.com>
Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
---
include/net/ip.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/include/net/ip.h b/include/net/ip.h
index 9742b92..bc43c0f 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -219,6 +219,29 @@ static inline u64 snmp_fold_field64(void __percpu *mib, int offt, size_t syncp_o
}
#endif
+#define snmp_get_cpu_field64_batch(buff64, stats_list, mib_statistic, offset) \
+{ \
+ int i, c; \
+ for_each_possible_cpu(c) { \
+ for (i = 0; stats_list[i].name; i++) \
+ buff64[i] += snmp_get_cpu_field64( \
+ mib_statistic, \
+ c, stats_list[i].entry, \
+ offset); \
+ } \
+}
+
+#define snmp_get_cpu_field_batch(buff, stats_list, mib_statistic) \
+{ \
+ int i, c; \
+ for_each_possible_cpu(c) { \
+ for (i = 0; stats_list[i].name; i++) \
+ buff[i] += snmp_get_cpu_field( \
+ mib_statistic, \
+ c, stats_list[i].entry); \
+ } \
+}
+
void inet_get_local_port_range(struct net *net, int *low, int *high);
#ifdef CONFIG_SYSCTL
--
2.5.5
^ permalink raw reply related
* [PATCH v5 7/7] net: Suppress the "Comparison to NULL could be written" warnings
From: Jia He @ 2016-09-28 6:22 UTC (permalink / raw)
To: netdev
Cc: linux-sctp, linux-kernel, davem, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Vlad Yasevich, Neil Horman,
Steffen Klassert, Herbert Xu, marcelo.leitner, Jia He
In-Reply-To: <1475043748-18161-1-git-send-email-hejianet@gmail.com>
This is to suppress the checkpatch.pl warning "Comparison to NULL
could be written". No functional changes here.
Signed-off-by: Jia He <hejianet@gmail.com>
---
net/ipv4/proc.c | 32 ++++++++++++++++----------------
net/sctp/proc.c | 2 +-
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index e01f4df..1a7a773 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -357,22 +357,22 @@ static void icmp_put(struct seq_file *seq)
atomic_long_t *ptr = net->mib.icmpmsg_statistics->mibs;
seq_puts(seq, "\nIcmp: InMsgs InErrors InCsumErrors");
- for (i = 0; icmpmibmap[i].name != NULL; i++)
+ for (i = 0; icmpmibmap[i].name; i++)
seq_printf(seq, " In%s", icmpmibmap[i].name);
seq_puts(seq, " OutMsgs OutErrors");
- for (i = 0; icmpmibmap[i].name != NULL; i++)
+ for (i = 0; icmpmibmap[i].name; i++)
seq_printf(seq, " Out%s", icmpmibmap[i].name);
seq_printf(seq, "\nIcmp: %lu %lu %lu",
snmp_fold_field(net->mib.icmp_statistics, ICMP_MIB_INMSGS),
snmp_fold_field(net->mib.icmp_statistics, ICMP_MIB_INERRORS),
snmp_fold_field(net->mib.icmp_statistics, ICMP_MIB_CSUMERRORS));
- for (i = 0; icmpmibmap[i].name != NULL; i++)
+ for (i = 0; icmpmibmap[i].name; i++)
seq_printf(seq, " %lu",
atomic_long_read(ptr + icmpmibmap[i].index));
seq_printf(seq, " %lu %lu",
snmp_fold_field(net->mib.icmp_statistics, ICMP_MIB_OUTMSGS),
snmp_fold_field(net->mib.icmp_statistics, ICMP_MIB_OUTERRORS));
- for (i = 0; icmpmibmap[i].name != NULL; i++)
+ for (i = 0; icmpmibmap[i].name; i++)
seq_printf(seq, " %lu",
atomic_long_read(ptr + (icmpmibmap[i].index | 0x100)));
}
@@ -389,7 +389,7 @@ static int snmp_seq_show_ipstats(struct seq_file *seq, void *v)
memset(buff64, 0, IPSTATS_MIB_MAX * sizeof(u64));
seq_puts(seq, "Ip: Forwarding DefaultTTL");
- for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
+ for (i = 0; snmp4_ipstats_list[i].name; i++)
seq_printf(seq, " %s", snmp4_ipstats_list[i].name);
seq_printf(seq, "\nIp: %d %d",
@@ -400,7 +400,7 @@ static int snmp_seq_show_ipstats(struct seq_file *seq, void *v)
snmp_get_cpu_field64_batch(buff64, snmp4_ipstats_list,
net->mib.ip_statistics,
offsetof(struct ipstats_mib, syncp));
- for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
+ for (i = 0; snmp4_ipstats_list[i].name; i++)
seq_printf(seq, " %llu", buff64[i]);
return 0;
@@ -415,13 +415,13 @@ static int snmp_seq_show_tcp_udp(struct seq_file *seq, void *v)
memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
seq_puts(seq, "\nTcp:");
- for (i = 0; snmp4_tcp_list[i].name != NULL; i++)
+ for (i = 0; snmp4_tcp_list[i].name; i++)
seq_printf(seq, " %s", snmp4_tcp_list[i].name);
seq_puts(seq, "\nTcp:");
snmp_get_cpu_field_batch(buff, snmp4_tcp_list,
net->mib.tcp_statistics);
- for (i = 0; snmp4_tcp_list[i].name != NULL; i++) {
+ for (i = 0; snmp4_tcp_list[i].name; i++) {
/* MaxConn field is signed, RFC 2012 */
if (snmp4_tcp_list[i].entry == TCP_MIB_MAXCONN)
seq_printf(seq, " %ld", buff[i]);
@@ -434,10 +434,10 @@ static int snmp_seq_show_tcp_udp(struct seq_file *seq, void *v)
snmp_get_cpu_field_batch(buff, snmp4_udp_list,
net->mib.udp_statistics);
seq_puts(seq, "\nUdp:");
- for (i = 0; snmp4_udp_list[i].name != NULL; i++)
+ for (i = 0; snmp4_udp_list[i].name; i++)
seq_printf(seq, " %s", snmp4_udp_list[i].name);
seq_puts(seq, "\nUdp:");
- for (i = 0; snmp4_udp_list[i].name != NULL; i++)
+ for (i = 0; snmp4_udp_list[i].name; i++)
seq_printf(seq, " %lu", buff[i]);
memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
@@ -446,10 +446,10 @@ static int snmp_seq_show_tcp_udp(struct seq_file *seq, void *v)
seq_puts(seq, "\nUdpLite:");
snmp_get_cpu_field_batch(buff, snmp4_udp_list,
net->mib.udplite_statistics);
- for (i = 0; snmp4_udp_list[i].name != NULL; i++)
+ for (i = 0; snmp4_udp_list[i].name; i++)
seq_printf(seq, " %s", snmp4_udp_list[i].name);
seq_puts(seq, "\nUdpLite:");
- for (i = 0; snmp4_udp_list[i].name != NULL; i++)
+ for (i = 0; snmp4_udp_list[i].name; i++)
seq_printf(seq, " %lu", buff[i]);
seq_putc(seq, '\n');
@@ -492,21 +492,21 @@ static int netstat_seq_show(struct seq_file *seq, void *v)
struct net *net = seq->private;
seq_puts(seq, "TcpExt:");
- for (i = 0; snmp4_net_list[i].name != NULL; i++)
+ for (i = 0; snmp4_net_list[i].name; i++)
seq_printf(seq, " %s", snmp4_net_list[i].name);
seq_puts(seq, "\nTcpExt:");
- for (i = 0; snmp4_net_list[i].name != NULL; i++)
+ for (i = 0; snmp4_net_list[i].name; i++)
seq_printf(seq, " %lu",
snmp_fold_field(net->mib.net_statistics,
snmp4_net_list[i].entry));
seq_puts(seq, "\nIpExt:");
- for (i = 0; snmp4_ipextstats_list[i].name != NULL; i++)
+ for (i = 0; snmp4_ipextstats_list[i].name; i++)
seq_printf(seq, " %s", snmp4_ipextstats_list[i].name);
seq_puts(seq, "\nIpExt:");
- for (i = 0; snmp4_ipextstats_list[i].name != NULL; i++)
+ for (i = 0; snmp4_ipextstats_list[i].name; i++)
seq_printf(seq, " %llu",
snmp_fold_field64(net->mib.ip_statistics,
snmp4_ipextstats_list[i].entry,
diff --git a/net/sctp/proc.c b/net/sctp/proc.c
index 9e7f4a7..16d7f3f 100644
--- a/net/sctp/proc.c
+++ b/net/sctp/proc.c
@@ -81,7 +81,7 @@ static int sctp_snmp_seq_show(struct seq_file *seq, void *v)
snmp_get_cpu_field_batch(buff, sctp_snmp_list,
net->sctp.sctp_statistics);
- for (i = 0; sctp_snmp_list[i].name != NULL; i++)
+ for (i = 0; sctp_snmp_list[i].name; i++)
seq_printf(seq, "%-32s\t%ld\n", sctp_snmp_list[i].name,
buff[i]);
--
2.5.5
^ permalink raw reply related
* [PATCH v5 0/7] Reduce cache miss for snmp_fold_field
From: Jia He @ 2016-09-28 6:22 UTC (permalink / raw)
To: netdev
Cc: linux-sctp, linux-kernel, davem, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Vlad Yasevich, Neil Horman,
Steffen Klassert, Herbert Xu, marcelo.leitner, Jia He
In a PowerPc server with large cpu number(160), besides commit
a3a773726c9f ("net: Optimize snmp stat aggregation by walking all
the percpu data at once"), I watched several other snmp_fold_field
callsites which would cause high cache miss rate.
test source code:
================
My simple test case, which read from the procfs items endlessly:
/***********************************************************/
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#define LINELEN 2560
int main(int argc, char **argv)
{
int i;
int fd = -1 ;
int rdsize = 0;
char buf[LINELEN+1];
buf[LINELEN] = 0;
memset(buf,0,LINELEN);
if(1 >= argc) {
printf("file name empty\n");
return -1;
}
fd = open(argv[1], O_RDWR, 0644);
if(0 > fd){
printf("open error\n");
return -2;
}
for(i=0;i<0xffffffff;i++) {
while(0 < (rdsize = read(fd,buf,LINELEN))){
//nothing here
}
lseek(fd, 0, SEEK_SET);
}
close(fd);
return 0;
}
/**********************************************************/
compile and run:
================
gcc test.c -o test
perf stat -d -e cache-misses ./test /proc/net/snmp
perf stat -d -e cache-misses ./test /proc/net/snmp6
perf stat -d -e cache-misses ./test /proc/net/sctp/snmp
perf stat -d -e cache-misses ./test /proc/net/xfrm_stat
before the patch set:
====================
Performance counter stats for 'system wide':
355911097 cache-misses [40.08%]
2356829300 L1-dcache-loads [60.04%]
355642645 L1-dcache-load-misses # 15.09% of all L1-dcache hits [60.02%]
346544541 LLC-loads [59.97%]
389763 LLC-load-misses # 0.11% of all LL-cache hits [40.02%]
6.245162638 seconds time elapsed
After the patch set:
===================
Performance counter stats for 'system wide':
194992476 cache-misses [40.03%]
6718051877 L1-dcache-loads [60.07%]
194871921 L1-dcache-load-misses # 2.90% of all L1-dcache hits [60.11%]
187632232 LLC-loads [60.04%]
464466 LLC-load-misses # 0.25% of all LL-cache hits [39.89%]
6.868422769 seconds time elapsed
The cache-miss rate can be reduced from 15% to 2.9%
changelog
=========
v5:
- order local variables from longest to shortest line
v4:
- move memset into one block of if statement in snmp6_seq_show_item
- remove the changes in netstat_seq_show considerred the stack usage is too large
v3:
- introduce generic interface (suggested by Marcelo Ricardo Leitner)
- use max_t instead of self defined macro (suggested by David Miller)
v2:
- fix bug in udplite statistics.
- snmp_seq_show is split into 2 parts
Jia He (7):
net:snmp: Introduce generic interfaces for snmp_get_cpu_field{,64}
proc: Reduce cache miss in snmp_seq_show
proc: Reduce cache miss in snmp6_seq_show
proc: Reduce cache miss in sctp_snmp_seq_show
proc: Reduce cache miss in xfrm_statistics_seq_show
ipv6: Remove useless parameter in __snmp6_fill_statsdev
net: Suppress the "Comparison to NULL could be written" warnings
include/net/ip.h | 23 ++++++++++++
net/ipv4/proc.c | 100 +++++++++++++++++++++++++++++++--------------------
net/ipv6/addrconf.c | 12 +++----
net/ipv6/proc.c | 32 ++++++++++++-----
net/sctp/proc.c | 12 ++++---
net/xfrm/xfrm_proc.c | 12 +++++--
6 files changed, 131 insertions(+), 60 deletions(-)
--
2.5.5
^ permalink raw reply
* [PATCH v5 2/7] proc: Reduce cache miss in snmp_seq_show
From: Jia He @ 2016-09-28 6:22 UTC (permalink / raw)
To: netdev
Cc: linux-sctp, linux-kernel, davem, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Vlad Yasevich, Neil Horman,
Steffen Klassert, Herbert Xu, marcelo.leitner, Jia He
In-Reply-To: <1475043748-18161-1-git-send-email-hejianet@gmail.com>
This is to use the generic interfaces snmp_get_cpu_field{,64}_batch to
aggregate the data by going through all the items of each cpu sequentially.
Then snmp_seq_show is split into 2 parts to avoid build warning "the frame
size" larger than 1024.
Signed-off-by: Jia He <hejianet@gmail.com>
---
net/ipv4/proc.c | 68 ++++++++++++++++++++++++++++++++++++++-------------------
1 file changed, 46 insertions(+), 22 deletions(-)
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 9f665b6..e01f4df 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -46,6 +46,8 @@
#include <net/sock.h>
#include <net/raw.h>
+#define TCPUDP_MIB_MAX max_t(u32, UDP_MIB_MAX, TCP_MIB_MAX)
+
/*
* Report socket allocation statistics [mea@utu.fi]
*/
@@ -378,13 +380,15 @@ static void icmp_put(struct seq_file *seq)
/*
* Called from the PROCfs module. This outputs /proc/net/snmp.
*/
-static int snmp_seq_show(struct seq_file *seq, void *v)
+static int snmp_seq_show_ipstats(struct seq_file *seq, void *v)
{
int i;
+ u64 buff64[IPSTATS_MIB_MAX];
struct net *net = seq->private;
- seq_puts(seq, "Ip: Forwarding DefaultTTL");
+ memset(buff64, 0, IPSTATS_MIB_MAX * sizeof(u64));
+ seq_puts(seq, "Ip: Forwarding DefaultTTL");
for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_ipstats_list[i].name);
@@ -393,57 +397,77 @@ static int snmp_seq_show(struct seq_file *seq, void *v)
net->ipv4.sysctl_ip_default_ttl);
BUILD_BUG_ON(offsetof(struct ipstats_mib, mibs) != 0);
+ snmp_get_cpu_field64_batch(buff64, snmp4_ipstats_list,
+ net->mib.ip_statistics,
+ offsetof(struct ipstats_mib, syncp));
for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
- seq_printf(seq, " %llu",
- snmp_fold_field64(net->mib.ip_statistics,
- snmp4_ipstats_list[i].entry,
- offsetof(struct ipstats_mib, syncp)));
+ seq_printf(seq, " %llu", buff64[i]);
- icmp_put(seq); /* RFC 2011 compatibility */
- icmpmsg_put(seq);
+ return 0;
+}
+
+static int snmp_seq_show_tcp_udp(struct seq_file *seq, void *v)
+{
+ int i;
+ struct net *net = seq->private;
+ unsigned long buff[TCPUDP_MIB_MAX];
+
+ memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
seq_puts(seq, "\nTcp:");
for (i = 0; snmp4_tcp_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_tcp_list[i].name);
seq_puts(seq, "\nTcp:");
+ snmp_get_cpu_field_batch(buff, snmp4_tcp_list,
+ net->mib.tcp_statistics);
for (i = 0; snmp4_tcp_list[i].name != NULL; i++) {
/* MaxConn field is signed, RFC 2012 */
if (snmp4_tcp_list[i].entry == TCP_MIB_MAXCONN)
- seq_printf(seq, " %ld",
- snmp_fold_field(net->mib.tcp_statistics,
- snmp4_tcp_list[i].entry));
+ seq_printf(seq, " %ld", buff[i]);
else
- seq_printf(seq, " %lu",
- snmp_fold_field(net->mib.tcp_statistics,
- snmp4_tcp_list[i].entry));
+ seq_printf(seq, " %lu", buff[i]);
}
+ memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
+
+ snmp_get_cpu_field_batch(buff, snmp4_udp_list,
+ net->mib.udp_statistics);
seq_puts(seq, "\nUdp:");
for (i = 0; snmp4_udp_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_udp_list[i].name);
-
seq_puts(seq, "\nUdp:");
for (i = 0; snmp4_udp_list[i].name != NULL; i++)
- seq_printf(seq, " %lu",
- snmp_fold_field(net->mib.udp_statistics,
- snmp4_udp_list[i].entry));
+ seq_printf(seq, " %lu", buff[i]);
+
+ memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
/* the UDP and UDP-Lite MIBs are the same */
seq_puts(seq, "\nUdpLite:");
+ snmp_get_cpu_field_batch(buff, snmp4_udp_list,
+ net->mib.udplite_statistics);
for (i = 0; snmp4_udp_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_udp_list[i].name);
-
seq_puts(seq, "\nUdpLite:");
for (i = 0; snmp4_udp_list[i].name != NULL; i++)
- seq_printf(seq, " %lu",
- snmp_fold_field(net->mib.udplite_statistics,
- snmp4_udp_list[i].entry));
+ seq_printf(seq, " %lu", buff[i]);
seq_putc(seq, '\n');
return 0;
}
+static int snmp_seq_show(struct seq_file *seq, void *v)
+{
+ snmp_seq_show_ipstats(seq, v);
+
+ icmp_put(seq); /* RFC 2011 compatibility */
+ icmpmsg_put(seq);
+
+ snmp_seq_show_tcp_udp(seq, v);
+
+ return 0;
+}
+
static int snmp_seq_open(struct inode *inode, struct file *file)
{
return single_open_net(inode, file, snmp_seq_show);
--
2.5.5
^ permalink raw reply related
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