* [PATCH v3] ipv6: notify userspace when we added or changed an ipv6 token
From: Lubomir Rintel @ 2014-10-27 16:39 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Lubomir Rintel, Hannes Frederic Sowa,
Daniel Borkmann
In-Reply-To: <544D8234.5060504@redhat.com>
NetworkManager might want to know that it changed when the router advertisement
arrives.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Daniel Borkmann <dborkman@redhat.com>
---
Changes since v1:
- Do not call device notifier chain with netdev_state_change()
Changes since v2:
- inet6_ifinfo_notify() instead of rtmsg_ifinfo()
net/ipv6/addrconf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 3e118df..d9269ef 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4528,6 +4528,7 @@ static int inet6_set_iftoken(struct inet6_dev *idev, struct in6_addr *token)
}
write_unlock_bh(&idev->lock);
+ inet6_ifinfo_notify(RTM_NEWLINK, idev);
addrconf_verify_rtnl();
return 0;
}
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] netlink: don't copy over empty attribute data
From: Andrey Ryabinin @ 2014-10-27 16:46 UTC (permalink / raw)
To: Sasha Levin, David Miller; +Cc: pablo, mschmidt, akpm, linux-kernel, netdev
In-Reply-To: <544E59DC.3060906@oracle.com>
On 10/27/2014 05:42 PM, Sasha Levin wrote:
> On 10/26/2014 10:03 PM, David Miller wrote:
>> From: Sasha Levin <sasha.levin@oracle.com>
>> Date: Sun, 26 Oct 2014 19:32:42 -0400
>>
>>> How so? GCC states clearly that you should *never* pass a NULL
>>> pointer there:
>>>
>>> "The pointers passed to memmove (and similar functions in <string.h>) must
>>> be non-null even when nbytes==0" (https://gcc.gnu.org/gcc-4.9/porting_to.html).
>>>
>>> Even if it doesn't dereference it, it can break somehow in a subtle way. Leaving
>>> the kernel code assuming that gcc (or any other compiler) would always behave
>>> the same in a situation that shouldn't occur.
>>
>> Show me a legal way in which one could legally dereference the pointer
>> when length is zero, and I'll entertain this patch.
>
> The moment you've triggered an undefined behaviour you have GCC license to
> dereference anything it wants. GCC would be well within it's rights
> dereferencing a NULL "from".
>
> They even state it clearly in that GCC 4.9 porting guide I've linked above:
>
> """
> Calling copy(p, NULL, 0) can therefore deference a null pointer and crash.
>
> The example above needs to be fixed to avoid the invalid memmove call, for example:
>
>
> if (nbytes != 0)
> memmove (dest, src, nbytes);
> """
>
In example from link null ptr deref could happen because GCC will optimize away null pointer check after
memmove():
int copy (int* dest, int* src, size_t nbytes) {
memmove (dest, src, nbytes);
if (src != NULL) <---- GCC will eliminate this check because src can't be null.
return *src; <-- NULL ptr deref
return 0;
}
Even though GCC and C standard treats such code ( memmove(dest, NULL, 0); ) as invalid, it probably will not crash in linux kernel case,
because that kind of optimization disabled via -fno-delete-null-pointer-checks option.
>
> Thanks,
> Sasha
>
^ permalink raw reply
* Re: [PATCH] ovs: Turn vports with dependencies into separate modules
From: Pravin Shelar @ 2014-10-27 17:14 UTC (permalink / raw)
To: Thomas Graf; +Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, netdev
In-Reply-To: <20141024215758.GA25640-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
On Fri, Oct 24, 2014 at 2:57 PM, Thomas Graf <tgraf@suug.ch> wrote:
> On 10/24/14 at 10:47am, Pravin Shelar wrote:
>> On Wed, Oct 22, 2014 at 8:29 AM, Thomas Graf <tgraf@suug.ch> wrote:
>> > The internal and netdev vport remain part of openvswitch.ko. Encap
>> > vports including vxlan, gre, and geneve can be built as separate
>> > modules and are loaded on demand. Modules can be unloaded after use.
>> > Datapath ports keep a reference to the vport module during their
>> > lifetime.
>> >
>> > Allows to remove the error prone maintenance of the global list
>> > vport_ops_list.
>> >
>> How error prone is this interface, can you give example? Set of ovs
>> vport type is been pretty stable, so am not sure if we need loadable
>> module support for vports implementations.
>
> I was refering to how many other kernel APIs have been designed, a
> registration API allowing a vport to be implemented exclusively in the
> scope of a single file tends to be cleaner than having to touch multiple
> files and maintaining an init list.
>
This has never been issue in openvswitch. Plus we do not need loadable
vport module to fix this issue.
> It also allows for OVS to be built into vmlinuz while vports can
> remain as modules even if vxlan itself is built as a module.
>
What is problem with current OVS built into kernel?
> As for new vports, GUE and LIS are candidates, encrypted VXLAN might
> look for support and there are several VXLAN extensions currently
> proposed as IETF drafts which might require new vports.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* [PATCH net-next] net: skb_segment() should preserve backpressure
From: Eric Dumazet @ 2014-10-27 17:30 UTC (permalink / raw)
To: Toshiaki Makita, David Miller; +Cc: netdev, Herbert Xu
In-Reply-To: <1414424388.16231.13.camel@edumazet-glaptop2.roam.corp.google.com>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
This patch generalizes commit d6a4a1041176 ("tcp: GSO should be TSQ
friendly") to protocols using skb_set_owner_w()
TCP uses its own destructor (tcp_wfree) and needs a more complex scheme
as explained in commit 6ff50cd55545 ("tcp: gso: do not generate out of
order packets")
This allows UDP sockets using UFO to get proper backpressure,
thus avoiding qdisc drops and excessive cpu usage.
Here are performance test results (macvlan on vlan):
- Before
# netperf -t UDP_STREAM ...
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 65507 60.00 144096 1224195 1258.56
212992 60.00 51 0.45
Average: CPU %user %nice %system %iowait %steal %idle
Average: all 0.23 0.00 25.26 0.08 0.00 74.43
- After
# netperf -t UDP_STREAM ...
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 65507 60.00 109593 0 957.20
212992 60.00 109593 957.20
Average: CPU %user %nice %system %iowait %steal %idle
Average: all 0.18 0.00 8.38 0.02 0.00 91.43
[edumazet] Rewrote patch and changelog.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/skbuff.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index c16615bfb61edd2a1dae9ef7935a3153d78dc4df..e48e5c02e877d9a9389ea54f0e015ba041d3f2a7 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3099,6 +3099,16 @@ perform_csum_check:
* (see validate_xmit_skb_list() for example)
*/
segs->prev = tail;
+
+ /* Following permits correct backpressure, for protocols
+ * using skb_set_owner_w().
+ * Idea is to tranfert ownership from head_skb to last segment.
+ */
+ if (head_skb->destructor == sock_wfree) {
+ swap(tail->truesize, head_skb->truesize);
+ swap(tail->destructor, head_skb->destructor);
+ swap(tail->sk, head_skb->sk);
+ }
return segs;
err:
^ permalink raw reply related
* Re: [PATCH 08/11] ssb: driver_chip_comon_pmu: Fix probable mask then right shift defect
From: Michael Büsch @ 2014-10-27 17:32 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-kernel, netdev
In-Reply-To: <e68a49a228d8d2495630b4ef03a1f32b33fce7fe.1414387334.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]
On Sun, 26 Oct 2014 22:25:04 -0700
Joe Perches <joe@perches.com> wrote:
> Precedence of & and >> is not the same and is not left to right.
> shift has higher precedence and should be done after the mask.
>
> Add parentheses around the mask.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Good catch.
Reviewed-by: Michael Büsch <m@bues.ch>
> ---
> drivers/ssb/driver_chipcommon_pmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ssb/driver_chipcommon_pmu.c b/drivers/ssb/driver_chipcommon_pmu.c
> index 1173a09..bc71583 100644
> --- a/drivers/ssb/driver_chipcommon_pmu.c
> +++ b/drivers/ssb/driver_chipcommon_pmu.c
> @@ -621,8 +621,8 @@ static u32 ssb_pmu_get_alp_clock_clk0(struct ssb_chipcommon *cc)
> u32 crystalfreq;
> const struct pmu0_plltab_entry *e = NULL;
>
> - crystalfreq = chipco_read32(cc, SSB_CHIPCO_PMU_CTL) &
> - SSB_CHIPCO_PMU_CTL_XTALFREQ >> SSB_CHIPCO_PMU_CTL_XTALFREQ_SHIFT;
> + crystalfreq = (chipco_read32(cc, SSB_CHIPCO_PMU_CTL) &
> + SSB_CHIPCO_PMU_CTL_XTALFREQ) >> SSB_CHIPCO_PMU_CTL_XTALFREQ_SHIFT;
> e = pmu0_plltab_find_entry(crystalfreq);
> BUG_ON(!e);
> return e->freq * 1000;
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-27 17:45 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang,
Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj
In-Reply-To: <20141025181827.GE28247@linux.vnet.ibm.com>
On Sat, Oct 25, 2014 at 11:18:27AM -0700, Paul E. McKenney wrote:
> On Sat, Oct 25, 2014 at 09:38:16AM -0700, Jay Vosburgh wrote:
> > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> >
> > >On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote:
> > >> Looking at the dmesg, the early boot messages seem to be
> > >> confused as to how many CPUs there are, e.g.,
> > >>
> > >> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> > >> [ 0.000000] Hierarchical RCU implementation.
> > >> [ 0.000000] RCU debugfs-based tracing is enabled.
> > >> [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled.
> > >> [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4.
> > >> [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
> > >> [ 0.000000] NR_IRQS:16640 nr_irqs:456 0
> > >> [ 0.000000] Offload RCU callbacks from all CPUs
> > >> [ 0.000000] Offload RCU callbacks from CPUs: 0-3.
> > >>
> > >> but later shows 2:
> > >>
> > >> [ 0.233703] x86: Booting SMP configuration:
> > >> [ 0.236003] .... node #0, CPUs: #1
> > >> [ 0.255528] x86: Booted up 1 node, 2 CPUs
> > >>
> > >> In any event, the E8400 is a 2 core CPU with no hyperthreading.
> > >
> > >Well, this might explain some of the difficulties. If RCU decides to wait
> > >on CPUs that don't exist, we will of course get a hang. And rcu_barrier()
> > >was definitely expecting four CPUs.
> > >
> > >So what happens if you boot with maxcpus=2? (Or build with
> > >CONFIG_NR_CPUS=2.) I suspect that this might avoid the hang. If so,
> > >I might have some ideas for a real fix.
> >
> > Booting with maxcpus=2 makes no difference (the dmesg output is
> > the same).
> >
> > Rebuilding with CONFIG_NR_CPUS=2 makes the problem go away, and
> > dmesg has different CPU information at boot:
> >
> > [ 0.000000] smpboot: 4 Processors exceeds NR_CPUS limit of 2
> > [ 0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs
> > [...]
> > [ 0.000000] setup_percpu: NR_CPUS:2 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1
> > [...]
> > [ 0.000000] Hierarchical RCU implementation.
> > [ 0.000000] RCU debugfs-based tracing is enabled.
> > [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled.
> > [ 0.000000] NR_IRQS:4352 nr_irqs:440 0
> > [ 0.000000] Offload RCU callbacks from all CPUs
> > [ 0.000000] Offload RCU callbacks from CPUs: 0-1.
>
> Thank you -- this confirms my suspicions on the fix, though I must admit
> to being surprised that maxcpus made no difference.
And here is an alleged fix, lightly tested at this end. Does this patch
help?
Thanx, Paul
------------------------------------------------------------------------
rcu: Make rcu_barrier() understand about missing rcuo kthreads
Commit 35ce7f29a44a (rcu: Create rcuo kthreads only for onlined CPUs)
avoids creating rcuo kthreads for CPUs that never come online. This
fixes a bug in many instances of firmware: Instead of lying about their
age, these systems instead lie about the number of CPUs that they have.
Before commit 35ce7f29a44a, this could result in huge numbers of useless
rcuo kthreads being created.
It appears that experience indicates that I should have told the
people suffering from this problem to fix their broken firmware, but
I instead produced what turned out to be a partial fix. The missing
piece supplied by this commit makes sure that rcu_barrier() knows not to
post callbacks for no-CBs CPUs that have not yet come online, because
otherwise rcu_barrier() will hang on systems having firmware that lies
about the number of CPUs.
It is tempting to simply have rcu_barrier() refuse to post a callback on
any no-CBs CPU that does not have an rcuo kthread. This unfortunately
does not work because rcu_barrier() is required to wait for all pending
callbacks. It is therefore required to wait even for those callbacks
that cannot possibly be invoked. Even if doing so hangs the system.
Given that posting a callback to a no-CBs CPU that does not yet have an
rcuo kthread can hang rcu_barrier(), It is tempting to report an error
in this case. Unfortunately, this will result in false positives at
boot time, when it is perfectly legal to post callbacks to the boot CPU
before the scheduler has started, in other words, before it is legal
to invoke rcu_barrier().
So this commit instead has rcu_barrier() avoid posting callbacks to
CPUs having neither rcuo kthread nor pending callbacks, and has it
complain bitterly if it finds CPUs having no rcuo kthread but some
pending callbacks. And when rcu_barrier() does find CPUs having no rcuo
kthread but pending callbacks, as noted earlier, it has no choice but
to hang indefinitely.
Reported-by: Yanko Kaneti <yaneti@declera.com>
Reported-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Reported-by: Meelis Roos <mroos@linux.ee>
Reported-by: Eric B Munson <emunson@akamai.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
index aa8e5eea3ab4..c78e88ce5ea3 100644
--- a/include/trace/events/rcu.h
+++ b/include/trace/events/rcu.h
@@ -660,18 +660,18 @@ TRACE_EVENT(rcu_torture_read,
/*
* Tracepoint for _rcu_barrier() execution. The string "s" describes
* the _rcu_barrier phase:
- * "Begin": rcu_barrier_callback() started.
- * "Check": rcu_barrier_callback() checking for piggybacking.
- * "EarlyExit": rcu_barrier_callback() piggybacked, thus early exit.
- * "Inc1": rcu_barrier_callback() piggyback check counter incremented.
- * "Offline": rcu_barrier_callback() found offline CPU
- * "OnlineNoCB": rcu_barrier_callback() found online no-CBs CPU.
- * "OnlineQ": rcu_barrier_callback() found online CPU with callbacks.
- * "OnlineNQ": rcu_barrier_callback() found online CPU, no callbacks.
+ * "Begin": _rcu_barrier() started.
+ * "Check": _rcu_barrier() checking for piggybacking.
+ * "EarlyExit": _rcu_barrier() piggybacked, thus early exit.
+ * "Inc1": _rcu_barrier() piggyback check counter incremented.
+ * "OfflineNoCB": _rcu_barrier() found callback on never-online CPU
+ * "OnlineNoCB": _rcu_barrier() found online no-CBs CPU.
+ * "OnlineQ": _rcu_barrier() found online CPU with callbacks.
+ * "OnlineNQ": _rcu_barrier() found online CPU, no callbacks.
* "IRQ": An rcu_barrier_callback() callback posted on remote CPU.
* "CB": An rcu_barrier_callback() invoked a callback, not the last.
* "LastCB": An rcu_barrier_callback() invoked the last callback.
- * "Inc2": rcu_barrier_callback() piggyback check counter incremented.
+ * "Inc2": _rcu_barrier() piggyback check counter incremented.
* The "cpu" argument is the CPU or -1 if meaningless, the "cnt" argument
* is the count of remaining callbacks, and "done" is the piggybacking count.
*/
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index f6880052b917..7680fc275036 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3312,11 +3312,16 @@ static void _rcu_barrier(struct rcu_state *rsp)
continue;
rdp = per_cpu_ptr(rsp->rda, cpu);
if (rcu_is_nocb_cpu(cpu)) {
- _rcu_barrier_trace(rsp, "OnlineNoCB", cpu,
- rsp->n_barrier_done);
- atomic_inc(&rsp->barrier_cpu_count);
- __call_rcu(&rdp->barrier_head, rcu_barrier_callback,
- rsp, cpu, 0);
+ if (!rcu_nocb_cpu_needs_barrier(rsp, cpu)) {
+ _rcu_barrier_trace(rsp, "OfflineNoCB", cpu,
+ rsp->n_barrier_done);
+ } else {
+ _rcu_barrier_trace(rsp, "OnlineNoCB", cpu,
+ rsp->n_barrier_done);
+ atomic_inc(&rsp->barrier_cpu_count);
+ __call_rcu(&rdp->barrier_head,
+ rcu_barrier_callback, rsp, cpu, 0);
+ }
} else if (ACCESS_ONCE(rdp->qlen)) {
_rcu_barrier_trace(rsp, "OnlineQ", cpu,
rsp->n_barrier_done);
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index 4beab3d2328c..8e7b1843896e 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -587,6 +587,7 @@ static void print_cpu_stall_info(struct rcu_state *rsp, int cpu);
static void print_cpu_stall_info_end(void);
static void zero_cpu_stall_ticks(struct rcu_data *rdp);
static void increment_cpu_stall_ticks(void);
+static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu);
static void rcu_nocb_gp_set(struct rcu_node *rnp, int nrq);
static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp);
static void rcu_init_one_nocb(struct rcu_node *rnp);
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 927c17b081c7..68c5b23b7173 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2050,6 +2050,33 @@ static void wake_nocb_leader(struct rcu_data *rdp, bool force)
}
/*
+ * Does the specified CPU need an RCU callback for the specified flavor
+ * of rcu_barrier()?
+ */
+static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu)
+{
+ struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
+ struct rcu_head *rhp;
+
+ /* No-CBs CPUs might have callbacks on any of three lists. */
+ rhp = ACCESS_ONCE(rdp->nocb_head);
+ if (!rhp)
+ rhp = ACCESS_ONCE(rdp->nocb_gp_head);
+ if (!rhp)
+ rhp = ACCESS_ONCE(rdp->nocb_follower_head);
+
+ /* Having no rcuo kthread but CBs after scheduler starts is bad! */
+ if (!ACCESS_ONCE(rdp->nocb_kthread) && rhp) {
+ /* RCU callback enqueued before CPU first came online??? */
+ pr_err("RCU: Never-onlined no-CBs CPU %d has CB %p\n",
+ cpu, rhp->func);
+ WARN_ON_ONCE(1);
+ }
+
+ return !!rhp;
+}
+
+/*
* Enqueue the specified string of rcu_head structures onto the specified
* CPU's no-CBs lists. The CPU is specified by rdp, the head of the
* string by rhp, and the tail of the string by rhtp. The non-lazy/lazy
@@ -2646,6 +2673,10 @@ static bool init_nocb_callback_list(struct rcu_data *rdp)
#else /* #ifdef CONFIG_RCU_NOCB_CPU */
+static bool rcu_nocb_cpu_needs_barrier(struct rcu_state *rsp, int cpu)
+{
+}
+
static void rcu_nocb_gp_cleanup(struct rcu_state *rsp, struct rcu_node *rnp)
{
}
^ permalink raw reply related
* [PATCH net] cxgb4vf: Replace repetitive pci device ID's with right ones
From: Hariprasad Shenai @ 2014-10-27 17:52 UTC (permalink / raw)
To: netdev; +Cc: davem, leedom, kumaras, nirranjan, santosh, anish,
Hariprasad Shenai
Replaced repetive Device ID's which got added in commit b961f9a48844ecf3
("cxgb4vf: Remove superfluous "idx" parameter of CH_DEVICE() macro")
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
.../net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index bfa398d..0b42bdd 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -2929,14 +2929,14 @@ static const struct pci_device_id cxgb4vf_pci_tbl[] = {
CH_DEVICE(0x480d), /* T480-cr */
CH_DEVICE(0x480e), /* T440-lp-cr */
CH_DEVICE(0x4880),
- CH_DEVICE(0x4880),
- CH_DEVICE(0x4880),
- CH_DEVICE(0x4880),
- CH_DEVICE(0x4880),
- CH_DEVICE(0x4880),
- CH_DEVICE(0x4880),
- CH_DEVICE(0x4880),
- CH_DEVICE(0x4880),
+ CH_DEVICE(0x4881),
+ CH_DEVICE(0x4882),
+ CH_DEVICE(0x4883),
+ CH_DEVICE(0x4884),
+ CH_DEVICE(0x4885),
+ CH_DEVICE(0x4886),
+ CH_DEVICE(0x4887),
+ CH_DEVICE(0x4888),
CH_DEVICE(0x5801), /* T520-cr */
CH_DEVICE(0x5802), /* T522-cr */
CH_DEVICE(0x5803), /* T540-cr */
--
1.7.1
^ permalink raw reply related
* [PATCH 1/1 net-next] net/irda: include linux/uaccess.h instead of asm/uaccess.h
From: Fabian Frederick @ 2014-10-27 18:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Fabian Frederick, Samuel Ortiz, David S. Miller, netdev
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/irda/ircomm/ircomm_tty_ioctl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/irda/ircomm/ircomm_tty_ioctl.c b/net/irda/ircomm/ircomm_tty_ioctl.c
index ce94385..2db24bd 100644
--- a/net/irda/ircomm/ircomm_tty_ioctl.c
+++ b/net/irda/ircomm/ircomm_tty_ioctl.c
@@ -31,8 +31,7 @@
#include <linux/termios.h>
#include <linux/tty.h>
#include <linux/serial.h>
-
-#include <asm/uaccess.h>
+#include <linux/uaccess.h>
#include <net/irda/irda.h>
#include <net/irda/irmod.h>
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 1/2] udp: Record RPS flow in socket operations
From: Tom Herbert @ 2014-10-27 18:01 UTC (permalink / raw)
To: davem, netdev
Add calls to sock_rps_record_flow for udp_sendmsg, udp_sendpage
and udp_recvmsg. This enables RFS for connected UDP sockets.
Tested:
Ran netperf UDP_RR with 200 flows, with and without UDP RSS enabled
Before fix:
No RSS
Client (connected UDP)
36.87% CPU utilization
Server (unconnected UDP)
33.64% CPU utilization
256/440/687 90/95/99% latencies
727273 tps
UDP RSS
Client
79.59% CPU utilization
Server
78.83% CPU utilization
116/159/226 90/95/99% latencies
1.60974e+06 tps
After fix:
No RSS
Client
44.38% CPU utilization
Server
50.46% CPU utilization
192/245/343 90/95/99% latencies
1.01413e+06
UDP RSS
Client
79.98% CPU utilization
Server
80.35% CPU utilization
113/158/230 90/95/99% latencies
1.60622e+06 tps
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv4/udp.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index cd0db54..9a0d346 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -881,6 +881,8 @@ int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
struct sk_buff *skb;
struct ip_options_data opt_copy;
+ sock_rps_record_flow(sk);
+
if (len > 0xFFFF)
return -EMSGSIZE;
@@ -1113,6 +1115,8 @@ int udp_sendpage(struct sock *sk, struct page *page, int offset,
struct udp_sock *up = udp_sk(sk);
int ret;
+ sock_rps_record_flow(sk);
+
if (flags & MSG_SENDPAGE_NOTLAST)
flags |= MSG_MORE;
@@ -1253,6 +1257,8 @@ int udp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
int is_udplite = IS_UDPLITE(sk);
bool slow;
+ sock_rps_record_flow(sk);
+
if (flags & MSG_ERRQUEUE)
return ip_recv_error(sk, msg, len, addr_len);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 2/2] udp: Reset flow table for flows over unconnected sockets
From: Tom Herbert @ 2014-10-27 18:01 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1414432875-23795-1-git-send-email-therbert@google.com>
When receiving a packet on an unconnected UDP socket clear the
flow table for the corresponding hash. This is needed so flows over
unconnected UDP sockets will use RPS instead of using what is
present in the flow table. In particular, this avoids having flows
over unconnected sockets be perpetually steered by unrelated
entries in the flow table (idle TCP connections for instance).
Tested:
First filled up the RPS flow tables by creating a bunch of TCP
connections and letting them turn idle. Next, run netperf UDP_RR
with 200 flows.
Before fix:
Client (connected UDP)
81.15% CPU uilization
Server (unneconnedted UDP)
83.63% CPU uilization
118/167/249 90/95/99% latencies
1.59215e+06 tps
After fix:
Client (connected UDP)
81.13% CPU uilization
Server (unneconnedted UDP)
80.68% CPU uilization
116/167/248 90/95/99% latencies
1.61048e+06 tps
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv4/udp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 9a0d346..e58d841 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1451,6 +1451,11 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
if (inet_sk(sk)->inet_daddr) {
sock_rps_save_rxhash(sk, skb);
sk_mark_napi_id(sk, skb);
+ } else {
+ /* For an unconnected socket reset flow hash so that related
+ * flow will use RPS.
+ */
+ sock_rps_reset_flow_hash(skb->hash);
}
rc = sock_queue_rcv_skb(sk, skb);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH 1/1] ipv4: remove set but unused variable sha
From: Fabian Frederick @ 2014-10-27 18:03 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
unsigned char *sha (source) was already in original git version
but was never used.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/ipv4/ipconfig.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 648fa14..a896da5 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -498,7 +498,7 @@ ic_rarp_recv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt
struct arphdr *rarp;
unsigned char *rarp_ptr;
__be32 sip, tip;
- unsigned char *sha, *tha; /* s for "source", t for "target" */
+ unsigned char *tha; /* t for "target" */
struct ic_device *d;
if (!net_eq(dev_net(dev), &init_net))
@@ -549,7 +549,6 @@ ic_rarp_recv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt
goto drop_unlock; /* should never happen */
/* Extract variable-width fields */
- sha = rarp_ptr;
rarp_ptr += dev->addr_len;
memcpy(&sip, rarp_ptr, 4);
rarp_ptr += 4;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1 net-next] ipx: replace long unsigned int by unsigned long
From: Fabian Frederick @ 2014-10-27 18:05 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, Arnaldo Carvalho de Melo, David S. Miller,
netdev
Use standard unsigned long.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/ipx/ipx_proc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipx/ipx_proc.c b/net/ipx/ipx_proc.c
index e15c16a..c0cb442 100644
--- a/net/ipx/ipx_proc.c
+++ b/net/ipx/ipx_proc.c
@@ -90,7 +90,7 @@ static int ipx_seq_route_show(struct seq_file *seq, void *v)
seq_printf(seq, "%08lX ", (unsigned long int)ntohl(rt->ir_net));
if (rt->ir_routed)
seq_printf(seq, "%08lX %02X%02X%02X%02X%02X%02X\n",
- (long unsigned int)ntohl(rt->ir_intrfc->if_netnum),
+ (unsigned long)ntohl(rt->ir_intrfc->if_netnum),
rt->ir_router_node[0], rt->ir_router_node[1],
rt->ir_router_node[2], rt->ir_router_node[3],
rt->ir_router_node[4], rt->ir_router_node[5]);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1 net-next] ipx: replace __inline__ by inline
From: Fabian Frederick @ 2014-10-27 18:09 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, Arnaldo Carvalho de Melo, David S. Miller,
netdev
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/ipx/af_ipx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c
index 91729b8..61ffe3c 100644
--- a/net/ipx/af_ipx.c
+++ b/net/ipx/af_ipx.c
@@ -306,7 +306,7 @@ void ipxitf_down(struct ipx_interface *intrfc)
spin_unlock_bh(&ipx_interfaces_lock);
}
-static __inline__ void __ipxitf_put(struct ipx_interface *intrfc)
+static inline void __ipxitf_put(struct ipx_interface *intrfc)
{
if (atomic_dec_and_test(&intrfc->refcnt))
__ipxitf_down(intrfc);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1 net-next] ipv6: replace min/casting by min_t
From: Fabian Frederick @ 2014-10-27 18:11 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/ipv6/addrconf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 725c763..50b95b2 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2315,8 +2315,8 @@ ok:
else
stored_lft = 0;
if (!update_lft && !create && stored_lft) {
- const u32 minimum_lft = min(
- stored_lft, (u32)MIN_VALID_LIFETIME);
+ const u32 minimum_lft = min_t(u32,
+ stored_lft, MIN_VALID_LIFETIME);
valid_lft = max(valid_lft, minimum_lft);
/* RFC4862 Section 5.5.3e:
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1 net-next] ipv6: include linux/uaccess.h instead of asm/uaccess.h
From: Fabian Frederick @ 2014-10-27 18:12 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/ipv6/exthdrs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index bfde361..601d896 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -47,7 +47,7 @@
#include <net/xfrm.h>
#endif
-#include <asm/uaccess.h>
+#include <linux/uaccess.h>
/*
* Parsing tlv encoded headers.
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/1 net-next] ipx: replace long unsigned int by unsigned long
From: Joe Perches @ 2014-10-27 18:22 UTC (permalink / raw)
To: Fabian Frederick
Cc: linux-kernel, Arnaldo Carvalho de Melo, David S. Miller, netdev
In-Reply-To: <1414433133-29161-1-git-send-email-fabf@skynet.be>
On Mon, 2014-10-27 at 19:05 +0100, Fabian Frederick wrote:
> Use standard unsigned long.
[]
> diff --git a/net/ipx/ipx_proc.c b/net/ipx/ipx_proc.c
[]
> @@ -90,7 +90,7 @@ static int ipx_seq_route_show(struct seq_file *seq, void *v)
> seq_printf(seq, "%08lX ", (unsigned long int)ntohl(rt->ir_net));
> if (rt->ir_routed)
> seq_printf(seq, "%08lX %02X%02X%02X%02X%02X%02X\n",
> - (long unsigned int)ntohl(rt->ir_intrfc->if_netnum),
> + (unsigned long)ntohl(rt->ir_intrfc->if_netnum),
Maybe better to use no cast at all
seq_printf(seq, "%08X %02X%02X%02X%02X%02X%02X\n",
ntohl(etc...),
^ permalink raw reply
* Re: [PATCH net-next 2/2] udp: Reset flow table for flows over unconnected sockets
From: Eric Dumazet @ 2014-10-27 18:43 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <1414432875-23795-2-git-send-email-therbert@google.com>
On Mon, 2014-10-27 at 11:01 -0700, Tom Herbert wrote:
> When receiving a packet on an unconnected UDP socket clear the
> flow table for the corresponding hash. This is needed so flows over
> unconnected UDP sockets will use RPS instead of using what is
> present in the flow table. In particular, this avoids having flows
> over unconnected sockets be perpetually steered by unrelated
> entries in the flow table (idle TCP connections for instance).
>
> Tested:
>
> First filled up the RPS flow tables by creating a bunch of TCP
> connections and letting them turn idle. Next, run netperf UDP_RR
> with 200 flows.
>
> Before fix:
> Client (connected UDP)
> 81.15% CPU uilization
> Server (unneconnedted UDP)
> 83.63% CPU uilization
> 118/167/249 90/95/99% latencies
> 1.59215e+06 tps
>
> After fix:
> Client (connected UDP)
> 81.13% CPU uilization
> Server (unneconnedted UDP)
> 80.68% CPU uilization
> 116/167/248 90/95/99% latencies
> 1.61048e+06 tps
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> net/ipv4/udp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 9a0d346..e58d841 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1451,6 +1451,11 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> if (inet_sk(sk)->inet_daddr) {
> sock_rps_save_rxhash(sk, skb);
> sk_mark_napi_id(sk, skb);
> + } else {
> + /* For an unconnected socket reset flow hash so that related
> + * flow will use RPS.
> + */
> + sock_rps_reset_flow_hash(skb->hash);
> }
I believe I already said this patch was wrong Tom.
We need something else for UDP packets.
Its not because RFS is wrong for UDP packets that we want to make it
worse for TCP traffic.
We do now want UDP packets to gradually make flow table empty.
^ permalink raw reply
* TCP NewReno and single retransmit
From: Marcelo Ricardo Leitner @ 2014-10-27 18:49 UTC (permalink / raw)
To: netdev
Hi,
We have a report from a customer saying that on a very calm connection, like
having only a single data packet within some minutes, if this packet gets to
be re-transmitted, retrans_stamp is only cleared when the next acked packet is
received. But this may make we abort the connection too soon if this next
packet also gets lost, because the reference for the initial loss is still for
a big while ago..
local-machine remote-machine
| |
send#1---->(*1)|--------> data#1 --------->|
| | |
RTO : :
| | |
---(*2)|----> data#1(retrans) ---->|
| (*3)|<---------- ACK <----------|
| | |
| : :
| : :
| : :
16 minutes (or more) :
| : :
| : :
| : :
| | |
send#2---->(*4)|--------> data#2 --------->|
| | |
RTO : :
| | |
---(*5)|----> data#2(retrans) ---->|
| | |
| | |
RTO*2 : :
| | |
| | |
ETIMEDOUT<----(*6)| |
(diagram is not mine)
ETIMEDOUT happens way too early, because that's based on (*2) stamp.
Question is, can't we really clear retrans_stamp on step (*3)? Like with:
@@ -2382,31 +2382,32 @@ static inline bool tcp_may_undo(const struct tcp_sock *tp)
static bool tcp_try_undo_recovery(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
if (tcp_may_undo(tp)) {
int mib_idx;
/* Happy end! We did not retransmit anything
* or our original transmission succeeded.
*/
DBGUNDO(sk, inet_csk(sk)->icsk_ca_state == TCP_CA_Loss ?
"loss" : "retrans");
tcp_undo_cwnd_reduction(sk, false);
if (inet_csk(sk)->icsk_ca_state == TCP_CA_Loss)
mib_idx = LINUX_MIB_TCPLOSSUNDO;
else
mib_idx = LINUX_MIB_TCPFULLUNDO;
NET_INC_STATS_BH(sock_net(sk), mib_idx);
}
if (tp->snd_una == tp->high_seq && tcp_is_reno(tp)) {
/* Hold old state until something *above* high_seq
* is ACKed. For Reno it is MUST to prevent false
* fast retransmits (RFC2582). SACK TCP is safe. */
tcp_moderate_cwnd(tp);
+ tp->retrans_stamp = 0;
return true;
}
tcp_set_ca_state(sk, TCP_CA_Open);
return false;
}
We would still hold state, at least part of it.. WDYT?
Thanks,
Marcelo
^ permalink raw reply
* Re: [PATCH net-next 1/2] udp: Record RPS flow in socket operations
From: Eric Dumazet @ 2014-10-27 18:50 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <1414432875-23795-1-git-send-email-therbert@google.com>
On Mon, 2014-10-27 at 11:01 -0700, Tom Herbert wrote:
> Add calls to sock_rps_record_flow for udp_sendmsg, udp_sendpage
> and udp_recvmsg. This enables RFS for connected UDP sockets.
>
> Tested:
...
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> net/ipv4/udp.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index cd0db54..9a0d346 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -881,6 +881,8 @@ int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
> struct sk_buff *skb;
> struct ip_options_data opt_copy;
>
> + sock_rps_record_flow(sk);
> +
> if (len > 0xFFFF)
> return -EMSGSIZE;
>
> @@ -1113,6 +1115,8 @@ int udp_sendpage(struct sock *sk, struct page *page, int offset,
> struct udp_sock *up = udp_sk(sk);
> int ret;
>
> + sock_rps_record_flow(sk);
> +
> if (flags & MSG_SENDPAGE_NOTLAST)
> flags |= MSG_MORE;
>
> @@ -1253,6 +1257,8 @@ int udp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
> int is_udplite = IS_UDPLITE(sk);
> bool slow;
>
> + sock_rps_record_flow(sk);
> +
> if (flags & MSG_ERRQUEUE)
> return ip_recv_error(sk, msg, len, addr_len);
>
This patch is not needed.
All these paths go through af_inet.c and calls to sock_rps_record_flow()
are already done in inet_sendmsg(), inet_sendpage(), inet_recvmsg()
I wonder what you actually tested.
^ permalink raw reply
* [PATCH 1/1 net-next] ipx: move extern sysctl_ipx_pprop_broadcasting to header file
From: Fabian Frederick @ 2014-10-27 19:00 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, Arnaldo Carvalho de Melo, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, netdev
include ipx.h from sysctl_net_ipx.c
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
include/net/ipx.h | 3 +++
net/ipx/sysctl_net_ipx.c | 4 +---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/net/ipx.h b/include/net/ipx.h
index 0143180..320f47b 100644
--- a/include/net/ipx.h
+++ b/include/net/ipx.h
@@ -42,6 +42,9 @@ struct ipxhdr {
struct ipx_address ipx_source __packed;
};
+/* From af_ipx.c */
+extern int sysctl_ipx_pprop_broadcasting;
+
static __inline__ struct ipxhdr *ipx_hdr(struct sk_buff *skb)
{
return (struct ipxhdr *)skb_transport_header(skb);
diff --git a/net/ipx/sysctl_net_ipx.c b/net/ipx/sysctl_net_ipx.c
index ad7c03d..0dafcc5 100644
--- a/net/ipx/sysctl_net_ipx.c
+++ b/net/ipx/sysctl_net_ipx.c
@@ -9,14 +9,12 @@
#include <linux/mm.h>
#include <linux/sysctl.h>
#include <net/net_namespace.h>
+#include <net/ipx.h>
#ifndef CONFIG_SYSCTL
#error This file should not be compiled without CONFIG_SYSCTL defined
#endif
-/* From af_ipx.c */
-extern int sysctl_ipx_pprop_broadcasting;
-
static struct ctl_table ipx_table[] = {
{
.procname = "ipx_pprop_broadcasting",
--
1.9.1
^ permalink raw reply related
* nfs stalls over loopback interface (no sk_data_ready events?)
From: Jeff Layton @ 2014-10-27 19:26 UTC (permalink / raw)
To: netdev-DgEjT+Ai2ygdnm+yROfE0A
Cc: Christoph Hellwig, Linux NFS Mailing List, Bruce Fields,
Trond Myklebust
Sending this to netdev since I think I've now determined that this is
not a NFS specific problem. Recently Christoph mentioned that he was
seeing stalls when running xfstests generic/075 test on NFS over the
loopback interface with v3.18-rc1-ish kernel.
The configuration in this case is the nfs server and client on same box
communicating over the lo interface.
Here's are tracepoints from a typical request as it's supposed to work:
mount.nfs-906 [002] ...1 22711.996969: xprt_transmit: xprt=0xffff8800ce961000 xid=0xa8a34513 status=0
nfsd-678 [000] ...1 22711.997082: svc_recv: rq_xid=0xa8a34513 status=164
nfsd-678 [000] ..s8 22711.997185: xprt_lookup_rqst: xprt=0xffff8800ce961000 xid=0xa8a34513 status=0
nfsd-678 [000] ..s8 22711.997186: xprt_complete_rqst: xprt=0xffff8800ce961000 xid=0xa8a34513 status=140
nfsd-678 [000] ...1 22711.997236: svc_send: rq_xid=0xa8a34513 dropme=0 status=144
nfsd-678 [000] ...1 22711.997236: svc_process: rq_xid=0xa8a34513 dropme=0 status=144
...basically, we send a request to the server. Server picks it up and
sends the reply, and then the client IDs that reply and processes it.
This runs along just fine for ~ a minute or so. At some point, the
client stops seeing replies come in:
kworker/2:2-107 [002] ...1 22741.696070: xprt_transmit: xprt=0xffff8800ce961000 xid=0xc3a84513 status=0
nfsd-678 [002] .N.1 22741.696917: svc_recv: rq_xid=0xc3a84513 status=208
nfsd-678 [002] ...1 22741.699890: svc_send: rq_xid=0xc3a84513 dropme=0 status=262252
nfsd-678 [002] ...1 22741.699891: svc_process: rq_xid=0xc3a84513 dropme=0 status=262252
...a bit more tracepoint work seems to show that we just stop getting
sk_data_ready callbacks on the socket at all. I'm not terribly familiar
with the lower-level socket code, so I figured I'd email here and ask...
Anyone have insight into why this might be happening?
Thanks,
--
Jeff Layton <jlayton-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
* nfs stalls over loopback interface (no sk_data_ready events?)
From: Jeff Layton @ 2014-10-27 19:29 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Christoph Hellwig, Linux NFS Mailing List, Bruce Fields,
Trond Myklebust
(sorry for resend -- I got the netdev address wrong)
Sending this to netdev since I think I've now determined that this is
not a NFS specific problem. Recently Christoph mentioned that he was
seeing stalls when running xfstests generic/075 test on NFS over the
loopback interface with v3.18-rc1-ish kernel.
The configuration in this case is the nfs server and client on same box
communicating over the lo interface.
Here's are tracepoints from a typical request as it's supposed to work:
mount.nfs-906 [002] ...1 22711.996969: xprt_transmit: xprt=0xffff8800ce961000 xid=0xa8a34513 status=0
nfsd-678 [000] ...1 22711.997082: svc_recv: rq_xid=0xa8a34513 status=164
nfsd-678 [000] ..s8 22711.997185: xprt_lookup_rqst: xprt=0xffff8800ce961000 xid=0xa8a34513 status=0
nfsd-678 [000] ..s8 22711.997186: xprt_complete_rqst: xprt=0xffff8800ce961000 xid=0xa8a34513 status=140
nfsd-678 [000] ...1 22711.997236: svc_send: rq_xid=0xa8a34513 dropme=0 status=144
nfsd-678 [000] ...1 22711.997236: svc_process: rq_xid=0xa8a34513 dropme=0 status=144
...basically, we send a request to the server. Server picks it up and
sends the reply, and then the client IDs that reply and processes it.
This runs along just fine for ~ a minute or so. At some point, the
client stops seeing replies come in:
kworker/2:2-107 [002] ...1 22741.696070: xprt_transmit: xprt=0xffff8800ce961000 xid=0xc3a84513 status=0
nfsd-678 [002] .N.1 22741.696917: svc_recv: rq_xid=0xc3a84513 status=208
nfsd-678 [002] ...1 22741.699890: svc_send: rq_xid=0xc3a84513 dropme=0 status=262252
nfsd-678 [002] ...1 22741.699891: svc_process: rq_xid=0xc3a84513 dropme=0 status=262252
...a bit more tracepoint work seems to show that we just stop getting
sk_data_ready callbacks on the socket at all. I'm not terribly familiar
with the lower-level socket code, so I figured I'd email here and ask...
Anyone have insight into why this might be happening?
Thanks,
--
Jeff Layton <jlayton-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 2/2] udp: Reset flow table for flows over unconnected sockets
From: Tom Herbert @ 2014-10-27 19:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1414435437.32624.1.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Oct 27, 2014 at 11:43 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2014-10-27 at 11:01 -0700, Tom Herbert wrote:
>> When receiving a packet on an unconnected UDP socket clear the
>> flow table for the corresponding hash. This is needed so flows over
>> unconnected UDP sockets will use RPS instead of using what is
>> present in the flow table. In particular, this avoids having flows
>> over unconnected sockets be perpetually steered by unrelated
>> entries in the flow table (idle TCP connections for instance).
>>
>> Tested:
>>
>> First filled up the RPS flow tables by creating a bunch of TCP
>> connections and letting them turn idle. Next, run netperf UDP_RR
>> with 200 flows.
>>
>> Before fix:
>> Client (connected UDP)
>> 81.15% CPU uilization
>> Server (unneconnedted UDP)
>> 83.63% CPU uilization
>> 118/167/249 90/95/99% latencies
>> 1.59215e+06 tps
>>
>> After fix:
>> Client (connected UDP)
>> 81.13% CPU uilization
>> Server (unneconnedted UDP)
>> 80.68% CPU uilization
>> 116/167/248 90/95/99% latencies
>> 1.61048e+06 tps
>>
>> Signed-off-by: Tom Herbert <therbert@google.com>
>> ---
>> net/ipv4/udp.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
>> index 9a0d346..e58d841 100644
>> --- a/net/ipv4/udp.c
>> +++ b/net/ipv4/udp.c
>> @@ -1451,6 +1451,11 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
>> if (inet_sk(sk)->inet_daddr) {
>> sock_rps_save_rxhash(sk, skb);
>> sk_mark_napi_id(sk, skb);
>> + } else {
>> + /* For an unconnected socket reset flow hash so that related
>> + * flow will use RPS.
>> + */
>> + sock_rps_reset_flow_hash(skb->hash);
>> }
>
> I believe I already said this patch was wrong Tom.
>
> We need something else for UDP packets.
>
> Its not because RFS is wrong for UDP packets that we want to make it
> worse for TCP traffic.
>
Please try this patch and provide real data to support your points.
> We do now want UDP packets to gradually make flow table empty.
If a TCP connection is hot it will continually refresh the table for
that connection, if connection becomes idle it only takes one received
packet to restore the CPU. The only time there could be a persistent
problem is if collision rate is high (which probably means table is
too small).
>
>
>
>
^ permalink raw reply
* Re: [PATCH 1/1 net-next] ipx: replace long unsigned int by unsigned long
From: David Miller @ 2014-10-27 19:46 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, acme, netdev
In-Reply-To: <1414433133-29161-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Mon, 27 Oct 2014 19:05:33 +0100
> @@ -90,7 +90,7 @@ static int ipx_seq_route_show(struct seq_file *seq, void *v)
> seq_printf(seq, "%08lX ", (unsigned long int)ntohl(rt->ir_net));
> if (rt->ir_routed)
> seq_printf(seq, "%08lX %02X%02X%02X%02X%02X%02X\n",
> - (long unsigned int)ntohl(rt->ir_intrfc->if_netnum),
> + (unsigned long)ntohl(rt->ir_intrfc->if_netnum),
How about we kill the silly cast altogether and use plain %08X?
Thanks.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] ipx: replace __inline__ by inline
From: David Miller @ 2014-10-27 19:46 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, acme, netdev
In-Reply-To: <1414433352-29210-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Mon, 27 Oct 2014 19:09:12 +0100
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
If it's in a foo.c file, just kill the inline completely and let the
compiler decide.
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