* [PATCH v2] net: Add trace events for all receive exit points
From: Geneviève Bastien @ 2018-11-12 19:44 UTC (permalink / raw)
To: davem
Cc: netdev, Geneviève Bastien, Mathieu Desnoyers, Steven Rostedt,
Ingo Molnar
Trace events are already present for the receive entry points, to indicate
how the reception entered the stack.
This patch adds the corresponding exit trace events that will bound the
reception such that all events occurring between the entry and the exit
can be considered as part of the reception context. This greatly helps
for dependency and root cause analyses.
Without this, it is impossible to determine whether a sched_wakeup
event following a netif_receive_skb event is the result of the packet
reception or a simple coincidence after further processing by the
thread.
Signed-off-by: Geneviève Bastien <gbastien@versatic.net>
CC: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC: Steven Rostedt <rostedt@goodmis.org>
CC: Ingo Molnar <mingo@redhat.com>
CC: David S. Miller <davem@davemloft.net>
---
Changes in v2:
- Add the return value to tracepoints where applicable
- Verify if tracepoint is enabled before walking list in
netif_receive_skb_list
---
include/trace/events/net.h | 78 ++++++++++++++++++++++++++++++++++++++
net/core/dev.c | 38 ++++++++++++++++---
2 files changed, 110 insertions(+), 6 deletions(-)
diff --git a/include/trace/events/net.h b/include/trace/events/net.h
index 00aa72ce0e7c..cff1a7b9d0bb 100644
--- a/include/trace/events/net.h
+++ b/include/trace/events/net.h
@@ -117,6 +117,42 @@ DECLARE_EVENT_CLASS(net_dev_template,
__get_str(name), __entry->skbaddr, __entry->len)
)
+DECLARE_EVENT_CLASS(net_dev_template_return,
+
+ TP_PROTO(struct sk_buff *skb, int ret),
+
+ TP_ARGS(skb, ret),
+
+ TP_STRUCT__entry(
+ __field(void *, skbaddr)
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ __entry->skbaddr = skb;
+ __entry->ret = ret;
+ ),
+
+ TP_printk("skbaddr=%p ret=%d", __entry->skbaddr, __entry->ret)
+)
+
+DECLARE_EVENT_CLASS(net_dev_template_simple,
+
+ TP_PROTO(struct sk_buff *skb),
+
+ TP_ARGS(skb),
+
+ TP_STRUCT__entry(
+ __field(void *, skbaddr)
+ ),
+
+ TP_fast_assign(
+ __entry->skbaddr = skb;
+ ),
+
+ TP_printk("skbaddr=%p", __entry->skbaddr)
+)
+
DEFINE_EVENT(net_dev_template, net_dev_queue,
TP_PROTO(struct sk_buff *skb),
@@ -244,6 +280,48 @@ DEFINE_EVENT(net_dev_rx_verbose_template, netif_rx_ni_entry,
TP_ARGS(skb)
);
+DEFINE_EVENT(net_dev_template_return, napi_gro_frags_exit,
+
+ TP_PROTO(struct sk_buff *skb, int ret),
+
+ TP_ARGS(skb, ret)
+);
+
+DEFINE_EVENT(net_dev_template_return, napi_gro_receive_exit,
+
+ TP_PROTO(struct sk_buff *skb, int ret),
+
+ TP_ARGS(skb, ret)
+);
+
+DEFINE_EVENT(net_dev_template_return, netif_receive_skb_exit,
+
+ TP_PROTO(struct sk_buff *skb, int ret),
+
+ TP_ARGS(skb, ret)
+);
+
+DEFINE_EVENT(net_dev_template_simple, netif_receive_skb_list_exit,
+
+ TP_PROTO(struct sk_buff *skb),
+
+ TP_ARGS(skb)
+);
+
+DEFINE_EVENT(net_dev_template_return, netif_rx_exit,
+
+ TP_PROTO(struct sk_buff *skb, int ret),
+
+ TP_ARGS(skb, ret)
+);
+
+DEFINE_EVENT(net_dev_template_return, netif_rx_ni_exit,
+
+ TP_PROTO(struct sk_buff *skb, int ret),
+
+ TP_ARGS(skb, ret)
+);
+
#endif /* _TRACE_NET_H */
/* This part must be outside protection */
diff --git a/net/core/dev.c b/net/core/dev.c
index 0ffcbdd55fa9..c4dc5df34abe 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4520,9 +4520,14 @@ static int netif_rx_internal(struct sk_buff *skb)
int netif_rx(struct sk_buff *skb)
{
+ int ret;
+
trace_netif_rx_entry(skb);
- return netif_rx_internal(skb);
+ ret = netif_rx_internal(skb);
+ trace_netif_rx_exit(skb, ret);
+
+ return ret;
}
EXPORT_SYMBOL(netif_rx);
@@ -4537,6 +4542,7 @@ int netif_rx_ni(struct sk_buff *skb)
if (local_softirq_pending())
do_softirq();
preempt_enable();
+ trace_netif_rx_ni_exit(skb, err);
return err;
}
@@ -5222,9 +5228,14 @@ static void netif_receive_skb_list_internal(struct list_head *head)
*/
int netif_receive_skb(struct sk_buff *skb)
{
+ int ret;
+
trace_netif_receive_skb_entry(skb);
- return netif_receive_skb_internal(skb);
+ ret = netif_receive_skb_internal(skb);
+ trace_netif_receive_skb_exit(skb, ret);
+
+ return ret;
}
EXPORT_SYMBOL(netif_receive_skb);
@@ -5244,9 +5255,15 @@ void netif_receive_skb_list(struct list_head *head)
if (list_empty(head))
return;
- list_for_each_entry(skb, head, list)
- trace_netif_receive_skb_list_entry(skb);
+ if (trace_netif_receive_skb_list_entry_enabled()) {
+ list_for_each_entry(skb, head, list)
+ trace_netif_receive_skb_list_entry(skb);
+ }
netif_receive_skb_list_internal(head);
+ if (trace_netif_receive_skb_list_exit_enabled()) {
+ list_for_each_entry(skb, head, list)
+ trace_netif_receive_skb_list_exit(skb);
+ }
}
EXPORT_SYMBOL(netif_receive_skb_list);
@@ -5634,12 +5651,17 @@ static gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
gro_result_t napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
{
+ gro_result_t ret;
+
skb_mark_napi_id(skb, napi);
trace_napi_gro_receive_entry(skb);
skb_gro_reset_offset(skb);
- return napi_skb_finish(dev_gro_receive(napi, skb), skb);
+ ret = napi_skb_finish(dev_gro_receive(napi, skb), skb);
+ trace_napi_gro_receive_exit(skb, ret);
+
+ return ret;
}
EXPORT_SYMBOL(napi_gro_receive);
@@ -5753,6 +5775,7 @@ static struct sk_buff *napi_frags_skb(struct napi_struct *napi)
gro_result_t napi_gro_frags(struct napi_struct *napi)
{
+ gro_result_t ret;
struct sk_buff *skb = napi_frags_skb(napi);
if (!skb)
@@ -5760,7 +5783,10 @@ gro_result_t napi_gro_frags(struct napi_struct *napi)
trace_napi_gro_frags_entry(skb);
- return napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
+ ret = napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
+ trace_napi_gro_frags_exit(skb, ret);
+
+ return ret;
}
EXPORT_SYMBOL(napi_gro_frags);
--
2.19.1
^ permalink raw reply related
* Re: [PATCH bpf-next] bpftool: make libbfd optional
From: Jakub Kicinski @ 2018-11-12 19:42 UTC (permalink / raw)
To: Stanislav Fomichev; +Cc: netdev, ast, daniel, quentin.monnet
In-Reply-To: <20181112185328.125589-1-sdf@google.com>
On Mon, 12 Nov 2018 10:53:28 -0800, Stanislav Fomichev wrote:
> Make it possible to build bpftool without libbfd. This excludes support for
> disassembling jit-ted code and prints an error if the user tries to use
> these features.
>
> Tested by:
> cat > FEATURES_DUMP.bpftool <<EOF
> feature-libbfd=0
> feature-disassembler-four-args=1
> feature-reallocarray=0
> feature-libelf=1
> feature-libelf-mmap=1
> feature-bpf=1
> EOF
> FEATURES_DUMP=$PWD/FEATURES_DUMP.bpftool make
> ldd bpftool | grep libbfd
>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Would you mind spelling out the motivation?
> diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
> index 61d82020af58..ec1bc2ae3c71 100644
> --- a/tools/bpf/bpftool/main.h
> +++ b/tools/bpf/bpftool/main.h
> @@ -147,8 +147,19 @@ int prog_parse_fd(int *argc, char ***argv);
> int map_parse_fd(int *argc, char ***argv);
> int map_parse_fd_and_info(int *argc, char ***argv, void *info, __u32 *info_len);
>
> +#ifdef HAVE_LIBBFD_SUPPORT
> void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
> const char *arch, const char *disassembler_options);
> +void disasm_init(void);
> +#else
> +static inline
> +void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
> + const char *arch, const char *disassembler_options)
> +{
> + p_err("No libbfd support");
> +}
I think an error per instruction is a bit much, could we make sure we
error out earlier?
> +static inline void disasm_init(void) {}
> +#endif
> void print_data_json(uint8_t *data, size_t len);
> void print_hex_data_json(uint8_t *data, size_t len);
Otherwise LGTM.
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: Paweł Staszewski @ 2018-11-12 19:19 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Saeed Mahameed, netdev@vger.kernel.org
In-Reply-To: <20181111095627.6e2bf5cf@redhat.com>
W dniu 11.11.2018 o 09:56, Jesper Dangaard Brouer pisze:
> On Sat, 10 Nov 2018 22:53:53 +0100 Paweł Staszewski <pstaszewski@itcare.pl> wrote:
>
>> Now im messing with ring configuration for connectx5 nics.
>> And after reading that paper:
>> https://netdevconf.org/2.1/slides/apr6/network-performance/04-amir-RX_and_TX_bulking_v2.pdf
>>
> Do notice that some of the ideas in that slide deck, was never
> implemented. But they are still on my todo list ;-).
>
> Notice how that it show that TX bulking is very important, but based on
> your ethtool_stats.pl, I can see that not much TX bulking is happening
> in your case. This is indicated via the xmit_more counters.
>
> Ethtool(enp175s0) stat: 2630 ( 2,630) <= tx_xmit_more /sec
> Ethtool(enp175s0) stat: 4956995 ( 4,956,995) <= tx_packets /sec
>
> And the per queue levels are also avail:
>
> Ethtool(enp175s0) stat: 184845 ( 184,845) <= tx7_packets /sec
> Ethtool(enp175s0) stat: 78 ( 78) <= tx7_xmit_more /sec
>
> This means that you are doing too many doorbell's to the NIC hardware
> at TX time, which I worry could be what cause the NIC and PCIe hardware
> not to operate at optimal speeds.
After tunning coal/ring a little with ethtool
Reached today:
bwm-ng v0.6.1 (probing every 1.000s), press 'h' for help
input: /proc/net/dev type: rate
| iface Rx Tx Total
==============================================================================
enp175s0: 50.68 Gb/s 21.53 Gb/s
72.20 Gb/s
enp216s0: 21.62 Gb/s 50.81 Gb/s
72.42 Gb/s
------------------------------------------------------------------------------
total: 72.30 Gb/s 72.33 Gb/s
144.63 Gb/s
And still no packet loss (icmp side to side test every 100ms)
Below perf top
PerfTop: 104692 irqs/sec kernel:99.5% exact: 0.0% [4000Hz
cycles], (all, 56 CPUs)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.06% [kernel] [k] mlx5e_skb_from_cqe_mpwrq_linear
6.43% [kernel] [k] tasklet_action_common.isra.21
5.68% [kernel] [k] fib_table_lookup
4.89% [kernel] [k] irq_entries_start
4.53% [kernel] [k] mlx5_eq_int
4.10% [kernel] [k] build_skb
3.39% [kernel] [k] mlx5e_poll_tx_cq
3.38% [kernel] [k] mlx5e_sq_xmit
2.73% [kernel] [k] mlx5e_poll_rx_cq
2.18% [kernel] [k] __dev_queue_xmit
2.13% [kernel] [k] vlan_do_receive
2.12% [kernel] [k] mlx5e_handle_rx_cqe_mpwrq
2.00% [kernel] [k] ip_finish_output2
1.87% [kernel] [k] mlx5e_post_rx_mpwqes
1.86% [kernel] [k] memcpy_erms
1.85% [kernel] [k] ipt_do_table
1.70% [kernel] [k] dev_gro_receive
1.39% [kernel] [k] __netif_receive_skb_core
1.31% [kernel] [k] inet_gro_receive
1.21% [kernel] [k] ip_route_input_rcu
1.21% [kernel] [k] tcp_gro_receive
1.13% [kernel] [k] _raw_spin_lock
1.08% [kernel] [k] __build_skb
1.06% [kernel] [k] kmem_cache_free_bulk
1.05% [kernel] [k] __softirqentry_text_start
1.03% [kernel] [k] vlan_dev_hard_start_xmit
0.98% [kernel] [k] pfifo_fast_dequeue
0.95% [kernel] [k] mlx5e_xmit
0.95% [kernel] [k] page_frag_free
0.88% [kernel] [k] ip_forward
0.81% [kernel] [k] dev_hard_start_xmit
0.78% [kernel] [k] rcu_irq_exit
0.77% [kernel] [k] netif_skb_features
0.72% [kernel] [k] napi_complete_done
0.72% [kernel] [k] kmem_cache_alloc
0.68% [kernel] [k] validate_xmit_skb.isra.142
0.66% [kernel] [k] ip_rcv_core.isra.20.constprop.25
0.58% [kernel] [k] swiotlb_map_page
0.57% [kernel] [k] __qdisc_run
0.56% [kernel] [k] tasklet_action
0.54% [kernel] [k] __get_xps_queue_idx
0.54% [kernel] [k] inet_lookup_ifaddr_rcu
0.50% [kernel] [k] tcp4_gro_receive
0.49% [kernel] [k] skb_release_data
0.47% [kernel] [k] eth_type_trans
0.40% [kernel] [k] sch_direct_xmit
0.40% [kernel] [k] net_rx_action
0.39% [kernel] [k] __local_bh_enable_ip
And perf record/report
https://ufile.io/zguq0
So now i know what was causing cpu load for some processes like:
2913 root 20 0 0 0 0 I 10.3 0.0 6:58.29
kworker/u112:1-
7 root 20 0 0 0 0 I 8.6 0.0 6:17.18
kworker/u112:0-
10289 root 20 0 0 0 0 I 6.6 0.0 6:33.90
kworker/u112:4-
2939 root 20 0 0 0 0 R 3.6 0.0 7:37.68
kworker/u112:2-
After disabling adaptative tx for coalescense - all this processes gone.
lavg drops from 40 to 1
Current settings for coalescence:
ethtool -c enp175s0
Coalesce parameters for enp175s0:
Adaptive RX: off TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0
dmac: 32548
rx-usecs: 24
rx-frames: 256
rx-usecs-irq: 0
rx-frames-irq: 0
tx-usecs: 0
tx-frames: 64
tx-usecs-irq: 0
tx-frames-irq: 0
rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0
rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
And currently with that traffiv lvls - have no packet loss (cpu is avg.
60% for all 28 cores)
^ permalink raw reply
* Re: [PATCH net-next] net: phy: switch to lockdep_assert_held in phylib
From: Florian Fainelli @ 2018-11-12 18:58 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <20181112174416.GF5075@lunn.ch>
On 11/12/18 9:44 AM, Andrew Lunn wrote:
> On Sun, Nov 11, 2018 at 10:33:08PM +0100, Heiner Kallweit wrote:
>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>> index 2e59a8419..5cb06f021 100644
>> --- a/drivers/net/phy/mdio_bus.c
>> +++ b/drivers/net/phy/mdio_bus.c
>> @@ -541,7 +541,7 @@ int __mdiobus_read(struct mii_bus *bus, int addr, u32 regnum)
>> {
>> int retval;
>>
>> - WARN_ON_ONCE(!mutex_is_locked(&bus->mdio_lock));
>> + lockdep_assert_held_once(&bus->mdio_lock);
>
> Hi Heiner
>
> I don't think there is a clear right/wrong here. This is not hot path
> code. The cost for checking the lock is held is very small compared to
> the actual MDIO transaction. So i don't think we really need to
> optimise this. I do sometimes build with lockdep on, but not
> always. So it is good to know when locking is broken on normal builds.
>
> Florian, what do you think?
lockdep_assert_held_once() also looks at debug_locks (global variable)
so it sounds like in that regard, it would be superior in that it allows
an user-configurable, general debugging facility to behave consistently
as opposed to always having opt-in debugging within the mdio_bus.c file,
but that also has a lot of value. I have to admit debugging MDIO bus
locking issues is not particularly fun, so I would probably stick with
the current code in that regard.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next] net: phy: icplus: add config_intr callback
From: Florian Fainelli @ 2018-11-12 18:54 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <31282778-9e55-0f2e-da60-aea11a8c1182@gmail.com>
On 11/11/18 12:49 PM, Heiner Kallweit wrote:
> Move IRQ configuration for IP101A/G from config_init to config_intr
> callback. Reasons:
>
> 1. This allows phylib to disable interrupts if needed.
> 2. Icplus was the only driver supporting interrupts w/o defining a
> config_intr callback. Now we can add a phylib plausibility check
> disabling interrupt mode if one of the two irq-related callbacks
> isn't defined.
>
> I don't own hardware with this PHY, and the change is based on the
> datasheet for IP101A LF (which is supposed to be register-compatible
> with IP101A/G). Change is compile-tested only.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
A bit surprising that this is not a read/modify/write sequence.
--
Florian
^ permalink raw reply
* [PATCH bpf-next] bpftool: make libbfd optional
From: Stanislav Fomichev @ 2018-11-12 18:53 UTC (permalink / raw)
To: netdev, ast, daniel, jakub.kicinski, quentin.monnet; +Cc: Stanislav Fomichev
Make it possible to build bpftool without libbfd. This excludes support for
disassembling jit-ted code and prints an error if the user tries to use
these features.
Tested by:
cat > FEATURES_DUMP.bpftool <<EOF
feature-libbfd=0
feature-disassembler-four-args=1
feature-reallocarray=0
feature-libelf=1
feature-libelf-mmap=1
feature-bpf=1
EOF
FEATURES_DUMP=$PWD/FEATURES_DUMP.bpftool make
ldd bpftool | grep libbfd
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/bpf/bpftool/Makefile | 13 +++++++++++--
tools/bpf/bpftool/jit_disasm.c | 7 ++++++-
tools/bpf/bpftool/main.c | 3 +--
tools/bpf/bpftool/main.h | 11 +++++++++++
4 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index dac7eff4c7e5..1bea6b979082 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -53,7 +53,7 @@ ifneq ($(EXTRA_LDFLAGS),)
LDFLAGS += $(EXTRA_LDFLAGS)
endif
-LIBS = -lelf -lbfd -lopcodes $(LIBBPF)
+LIBS = -lelf $(LIBBPF)
INSTALL ?= install
RM ?= rm -f
@@ -90,7 +90,16 @@ include $(wildcard $(OUTPUT)*.d)
all: $(OUTPUT)bpftool
-SRCS = $(wildcard *.c)
+BFD_SRCS = jit_disasm.c
+
+SRCS = $(filter-out $(BFD_SRCS),$(wildcard *.c))
+
+ifeq ($(feature-libbfd),1)
+CFLAGS += -DHAVE_LIBBFD_SUPPORT
+SRCS += $(BFD_SRCS)
+LIBS += -lbfd -lopcodes
+endif
+
OBJS = $(patsubst %.c,$(OUTPUT)%.o,$(SRCS)) $(OUTPUT)disasm.o
$(OUTPUT)disasm.o: $(srctree)/kernel/bpf/disasm.c
diff --git a/tools/bpf/bpftool/jit_disasm.c b/tools/bpf/bpftool/jit_disasm.c
index c75ffd9ce2bb..6176bfe66f22 100644
--- a/tools/bpf/bpftool/jit_disasm.c
+++ b/tools/bpf/bpftool/jit_disasm.c
@@ -109,7 +109,7 @@ void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
if (inf) {
bfdf->arch_info = inf;
} else {
- p_err("No libfd support for %s", arch);
+ p_err("No libbfd support for %s", arch);
return;
}
}
@@ -183,3 +183,8 @@ void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
bfd_close(bfdf);
}
+
+void disasm_init(void)
+{
+ bfd_init();
+}
diff --git a/tools/bpf/bpftool/main.c b/tools/bpf/bpftool/main.c
index 75a3296dc0bc..51aa71069b14 100644
--- a/tools/bpf/bpftool/main.c
+++ b/tools/bpf/bpftool/main.c
@@ -31,7 +31,6 @@
* SOFTWARE.
*/
-#include <bfd.h>
#include <ctype.h>
#include <errno.h>
#include <getopt.h>
@@ -399,7 +398,7 @@ int main(int argc, char **argv)
if (argc < 0)
usage();
- bfd_init();
+ disasm_init();
ret = cmd_select(cmds, argc, argv, do_help);
diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
index 61d82020af58..ec1bc2ae3c71 100644
--- a/tools/bpf/bpftool/main.h
+++ b/tools/bpf/bpftool/main.h
@@ -147,8 +147,19 @@ int prog_parse_fd(int *argc, char ***argv);
int map_parse_fd(int *argc, char ***argv);
int map_parse_fd_and_info(int *argc, char ***argv, void *info, __u32 *info_len);
+#ifdef HAVE_LIBBFD_SUPPORT
void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
const char *arch, const char *disassembler_options);
+void disasm_init(void);
+#else
+static inline
+void disasm_print_insn(unsigned char *image, ssize_t len, int opcodes,
+ const char *arch, const char *disassembler_options)
+{
+ p_err("No libbfd support");
+}
+static inline void disasm_init(void) {}
+#endif
void print_data_json(uint8_t *data, size_t len);
void print_hex_data_json(uint8_t *data, size_t len);
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* Re: [PATCH bpf-next] filter: add BPF_ADJ_ROOM_DATA mode to bpf_skb_adjust_room()
From: Martin Lau @ 2018-11-12 18:39 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: ast@kernel.org, daniel@iogearbox.net, davem@davemloft.net,
netdev@vger.kernel.org
In-Reply-To: <a2e44e4c-03f3-5c8a-d209-c576da218395@6wind.com>
On Sun, Nov 11, 2018 at 12:43:27AM +0100, Nicolas Dichtel wrote:
> Le 09/11/2018 à 19:51, Martin Lau a écrit :
> > On Thu, Nov 08, 2018 at 04:11:37PM +0100, Nicolas Dichtel wrote:
> [snip]
> >> +static int bpf_skb_data_shrink(struct sk_buff *skb, u32 len)
> >> +{
> >> + unsigned short hhlen = skb->dev->header_ops ?
> >> + skb->dev->hard_header_len : 0;
> >> + int ret;
> >> +
> >> + ret = skb_unclone(skb, GFP_ATOMIC);
> >> + if (unlikely(ret < 0))
> >> + return ret;
> >> +
> >> + __skb_pull(skb, len);
> >> + skb_reset_mac_header(skb);
> >> + skb_reset_network_header(skb);
> >> + skb->network_header += hhlen;
Nit. skb_set_network_header(skb, hhlen);
Othen than that
Acked-by: Martin KaFai Lau <kafai@fb.com>
> >> + skb_reset_transport_header(skb);
> > hmm...why transport_header does not need += hhlen here
> > while network_header does?
>
> network_header is mandatory because bpf_redirect(BPF_F_INGRESS) can be called
> and network_header is expected to be correctly set in this case.
> For transport_header, I choose to not set it, because the stack will set it
> later (for example ip_rcv_core()).
ic. make sense.
^ permalink raw reply
* [PATCHv2 net-net] net: dsa: mv88e6xxx: Work around mv886e6161 SERDES missing MII_PHYSID2
From: Andrew Lunn @ 2018-11-12 17:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sergei.shtylyov, Andrew Lunn
We already have a workaround for a couple of switches whose internal
PHYs only have the Marvel OUI, but no model number. We detect such
PHYs and give them the 6390 ID as the model number. However the
mv88e6161 has two SERDES interfaces in the same address range as its
internal PHYs. These suffer from the same problem, the Marvell OUI,
but no model number. As a result, these SERDES interfaces were getting
the same PHY ID as the mv88e6390, even though they are not PHYs, and
the Marvell PHY driver was trying to drive them.
Add a special case to stop this from happen.
Reported-by: Chris Healy <Chris.Healy@zii.aero>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
v2:
grammar fix in commit message.
PHYS->PHYs
---
drivers/net/dsa/mv88e6xxx/chip.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index fc0f508879d4..b603f8d6ee3e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2524,11 +2524,22 @@ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
mutex_unlock(&chip->reg_lock);
if (reg == MII_PHYSID2) {
- /* Some internal PHYS don't have a model number. Use
- * the mv88e6390 family model number instead.
- */
- if (!(val & 0x3f0))
- val |= MV88E6XXX_PORT_SWITCH_ID_PROD_6390 >> 4;
+ /* Some internal PHYs don't have a model number. */
+ if (chip->info->family != MV88E6XXX_FAMILY_6165)
+ /* Then there is the 6165 family. It gets is
+ * PHYs correct. But it can also have two
+ * SERDES interfaces in the PHY address
+ * space. And these don't have a model
+ * number. But they are not PHYs, so we don't
+ * want to give them something a PHY driver
+ * will recognise.
+ *
+ * Use the mv88e6390 family model number
+ * instead, for anything which really could be
+ * a PHY,
+ */
+ if (!(val & 0x3f0))
+ val |= MV88E6XXX_PORT_SWITCH_ID_PROD_6390 >> 4;
}
return err ? err : val;
--
2.19.1
^ permalink raw reply related
* [PATCHv2] MAINTAINERS: Replace Vince Bridgers as Altera TSE maintainer
From: thor.thayer @ 2018-11-12 17:50 UTC (permalink / raw)
To: davem, netdev, gregkh; +Cc: vince.bridgers, atull, jhogan, Thor Thayer
From: Thor Thayer <thor.thayer@linux.intel.com>
Vince has moved to a different role. Replace him as Altera
TSE maintainer.
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
Acked-by: Vince Bridgers <vince.bridgers@intel.com>
Acked-by: Alan Tull <atull@kernel.org>
---
v2 Include netdev and David Miller
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e110e327bf38..827fd5fc6ebd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -717,7 +717,7 @@ F: include/linux/mfd/altera-a10sr.h
F: include/dt-bindings/reset/altr,rst-mgr-a10sr.h
ALTERA TRIPLE SPEED ETHERNET DRIVER
-M: Vince Bridgers <vbridger@opensource.altera.com>
+M: Thor Thayer <thor.thayer@linux.intel.com>
L: netdev@vger.kernel.org
L: nios2-dev@lists.rocketboards.org (moderated for non-subscribers)
S: Maintained
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] net: phy: switch to lockdep_assert_held in phylib
From: Andrew Lunn @ 2018-11-12 17:44 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <cdedf273-dfa3-1935-3352-cc86003c2a58@gmail.com>
On Sun, Nov 11, 2018 at 10:33:08PM +0100, Heiner Kallweit wrote:
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 2e59a8419..5cb06f021 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -541,7 +541,7 @@ int __mdiobus_read(struct mii_bus *bus, int addr, u32 regnum)
> {
> int retval;
>
> - WARN_ON_ONCE(!mutex_is_locked(&bus->mdio_lock));
> + lockdep_assert_held_once(&bus->mdio_lock);
Hi Heiner
I don't think there is a clear right/wrong here. This is not hot path
code. The cost for checking the lock is held is very small compared to
the actual MDIO transaction. So i don't think we really need to
optimise this. I do sometimes build with lockdep on, but not
always. So it is good to know when locking is broken on normal builds.
Florian, what do you think?
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: phy: icplus: add config_intr callback
From: Andrew Lunn @ 2018-11-12 17:34 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <31282778-9e55-0f2e-da60-aea11a8c1182@gmail.com>
On Sun, Nov 11, 2018 at 09:49:12PM +0100, Heiner Kallweit wrote:
> Move IRQ configuration for IP101A/G from config_init to config_intr
> callback. Reasons:
>
> 1. This allows phylib to disable interrupts if needed.
> 2. Icplus was the only driver supporting interrupts w/o defining a
> config_intr callback. Now we can add a phylib plausibility check
> disabling interrupt mode if one of the two irq-related callbacks
> isn't defined.
>
> I don't own hardware with this PHY, and the change is based on the
> datasheet for IP101A LF (which is supposed to be register-compatible
> with IP101A/G). Change is compile-tested only.
Hi Heiner
This looks sensible. Thanks for fixing up this driver.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 17/17] net: sched: unlock rules update API
From: David Miller @ 2018-11-12 17:30 UTC (permalink / raw)
To: vladbu; +Cc: netdev, jhs, xiyou.wangcong, jiri, ast, daniel
In-Reply-To: <1542009346-23780-18-git-send-email-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Mon, 12 Nov 2018 09:55:46 +0200
> Register netlink protocol handlers for message types RTM_NEWTFILTER,
> RTM_DELTFILTER, RTM_GETTFILTER as unlocked. Set rtnl_held variable that
> tracks rtnl mutex state to be false by default.
This whole conditional locking mechanism is really not clean and makes
this code so much harder to understand and audit.
Please improve the code so that this kind of construct is not needed.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next 02/17] net: sched: protect block state with spinlock
From: David Miller @ 2018-11-12 17:28 UTC (permalink / raw)
To: vladbu; +Cc: netdev, jhs, xiyou.wangcong, jiri, ast, daniel
In-Reply-To: <1542009346-23780-3-git-send-email-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Mon, 12 Nov 2018 09:55:31 +0200
> +#define ASSERT_BLOCK_LOCKED(block) \
> + WARN_ONCE(!spin_is_locked(&(block)->lock), \
> + "BLOCK: assertion failed at %s (%d)\n", __FILE__, __LINE__)
spin_is_locked() is not usable for assertions.
When SMP=n and DEBUG_SPINLOCK=n, it always returns zero.
^ permalink raw reply
* Re: [PATCH net-next 01/17] net: sched: refactor mini_qdisc_pair_swap() to use workqueue
From: David Miller @ 2018-11-12 17:28 UTC (permalink / raw)
To: vladbu; +Cc: netdev, jhs, xiyou.wangcong, jiri, ast, daniel
In-Reply-To: <1542009346-23780-2-git-send-email-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Mon, 12 Nov 2018 09:55:30 +0200
> +void mini_qdisc_pair_swap(struct mini_Qdisc_pair *miniqp,
> + struct tcf_proto *tp_head)
> +{
> + xchg(&miniqp->tp_head, tp_head);
If you are not checking the return value of xchg(), then this is
simply a store with optionally a memory barrier of some sort
either before or after.
^ permalink raw reply
* Re: [RFC PATCH 1/3] acpi: Add acpi mdio support code
From: Andrew Lunn @ 2018-11-12 17:25 UTC (permalink / raw)
To: Wang Dongsheng; +Cc: timur, yu.zheng, f.fainelli, rjw, linux-acpi, netdev
In-Reply-To: <2bf82b60c52bd3fc38b733e38fd991c9d31af6b9.1541660504.git.dongsheng.wang@hxt-semitech.com>
On Thu, Nov 08, 2018 at 03:22:16PM +0800, Wang Dongsheng wrote:
> Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
> The current implementation depend on mdio bus scan.
> With _DSD device properties we can finally do this:
>
> Device (MDIO) {
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "ethernet-phy@0", PHY0 }, }
> })
> Name (PHY0, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x0 }, }
> })
> }
>
> Device (MACO) {
> Name (_DSD, Package () {
> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
> })
> }
>
> Documentations:
> The DT "phy-handle" binding that we reuse for ACPI is documented in
> Documentation/devicetree/bindings/phy/phy-bindings.txt
>
> Documentation/acpi/dsd/data-node-references.txt
> Documentation/acpi/dsd/graph.txt
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
> ---
> drivers/acpi/Kconfig | 6 ++
> drivers/acpi/Makefile | 1 +
> drivers/acpi/acpi_mdio.c | 167 +++++++++++++++++++++++++++++++++++++
> drivers/net/phy/mdio_bus.c | 3 +
> include/linux/acpi_mdio.h | 82 ++++++++++++++++++
> 5 files changed, 259 insertions(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 9705fc986da9..0fefa3410ce9 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
> config ACPI_MCFG
> bool
>
> +config ACPI_MDIO
> + def_tristate PHYLIB
> + depends on PHYLIB
> + help
> + ACPI MDIO bus (Ethernet PHY) accessors
> +
> config ACPI_CPPC_LIB
> bool
> depends on ACPI_PROCESSOR
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 6d59aa109a91..ec7461a064fc 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -41,6 +41,7 @@ acpi-y += ec.o
> acpi-$(CONFIG_ACPI_DOCK) += dock.o
> acpi-y += pci_root.o pci_link.o pci_irq.o
> obj-$(CONFIG_ACPI_MCFG) += pci_mcfg.o
> +acpi-$(CONFIG_ACPI_MDIO) += acpi_mdio.o
> acpi-y += acpi_lpss.o acpi_apd.o
> acpi-y += acpi_platform.o
> acpi-y += acpi_pnp.o
> diff --git a/drivers/acpi/acpi_mdio.c b/drivers/acpi/acpi_mdio.c
> new file mode 100644
> index 000000000000..293bf9a63197
> --- /dev/null
> +++ b/drivers/acpi/acpi_mdio.c
> @@ -0,0 +1,167 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Lots of code in this file is copy from drivers/of/of_mdio.c
> +// Copyright (c) 2018 Huaxintong Semiconductor Technology Co., Ltd.
I agree with Rafael here. We should try to refactor and combine this
code. And where possible, we should try to add a uniform fwnode_ API
which underneath either uses OF or ACPI, depending on the type of the
node. We already have fwnode_get_mac_address(), fwmode_irq_get(),
fwnode_get_phy_mode(), so where possible, PHYs should be no different.
Andrew
^ permalink raw reply
* Re: [RFC PATCH 0/3] acpi: Add acpi mdio support code
From: Andrew Lunn @ 2018-11-12 17:20 UTC (permalink / raw)
To: Wang, Dongsheng
Cc: timur@kernel.org, Zheng, Joey, f.fainelli@gmail.com,
rjw@rjwysocki.net, linux-acpi@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <6ebdf08060c245a8a44fc4263eb308cc@HXTBJIDCEMVIW02.hxtcorp.net>
> > I'm just trying to ensure whatever is defined is flexible enough that
> > we really can later support everything which DT does. We have PHYs on
> > MDIO busses, inside switches, which are on MDIO busses, which are
> > inside Ethernet interfaces, etc.
>
> I think it can be satisfied. See the table I'm using above.
Hi Dongsheng
Since i don't know anything better, i think i have to trust you have
this correct.
It would be good to document this, so that the next person who needs
to add ACPI support for a PHY has some documentation to look at.
Could you add something to Documentation/acpi/dsd?
Andrew
^ permalink raw reply
* Re: [PATCHv2 net-next 0/3] sctp: add support for sk_reuseport
From: David Miller @ 2018-11-12 17:10 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <cover.1542018324.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 12 Nov 2018 18:27:14 +0800
> sctp sk_reuseport allows multiple socks to listen on the same port and
> addresses, as long as these socks have the same uid. This works pretty
> much as TCP/UDP does, the only difference is that sctp is multi-homing
> and all the bind_addrs in these socks will have to completely matched,
> otherwise listen() will return err.
>
> The below is when 5 sockets are listening on 172.16.254.254:6400 on a
> server, 26 sockets on a client connect to 172.16.254.254:6400 and each
> may be processed by a different socket on the server which is selected
> by hash(lport, pport, paddr) in reuseport_select_sock():
>
> # ss --sctp -nn
...
Series applied, thanks.
^ permalink raw reply
* [PATCH net] l2tp: fix a sock refcnt leak in l2tp_tunnel_register
From: Xin Long @ 2018-11-12 17:08 UTC (permalink / raw)
To: network dev; +Cc: davem, Guillaume Nault
This issue happens when trying to add an existent tunnel. It
doesn't call sock_put() before returning -EEXIST to release
the sock refcnt that was held by calling sock_hold() before
the existence check.
This patch is to fix it by holding the sock after doing the
existence check.
Fixes: f6cd651b056f ("l2tp: fix race in duplicate tunnel detection")
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/l2tp/l2tp_core.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 82cdf90..26f1d43 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1490,12 +1490,7 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net,
goto err_sock;
}
- sk = sock->sk;
-
- sock_hold(sk);
- tunnel->sock = sk;
tunnel->l2tp_net = net;
-
pn = l2tp_pernet(net);
spin_lock_bh(&pn->l2tp_tunnel_list_lock);
@@ -1510,6 +1505,10 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net,
list_add_rcu(&tunnel->list, &pn->l2tp_tunnel_list);
spin_unlock_bh(&pn->l2tp_tunnel_list_lock);
+ sk = sock->sk;
+ sock_hold(sk);
+ tunnel->sock = sk;
+
if (tunnel->encap == L2TP_ENCAPTYPE_UDP) {
struct udp_tunnel_sock_cfg udp_cfg = {
.sk_user_data = tunnel,
--
2.1.0
^ permalink raw reply related
* Re: [PATCH tip/core/rcu 2/7] sfc: Replace spin_is_locked() with lockdep
From: Paul E. McKenney @ 2018-11-12 17:07 UTC (permalink / raw)
To: Edward Cree
Cc: linux-kernel, mingo, jiangshanlai, dipankar, akpm,
mathieu.desnoyers, josh, tglx, peterz, rostedt, dhowells,
edumazet, fweisbec, oleg, joel, Lance Roy,
Solarflare linux maintainers, Bert Kenward, David S. Miller,
netdev
In-Reply-To: <d5a895b9-6d0b-1d51-dc97-96864c5335af@solarflare.com>
On Mon, Nov 12, 2018 at 01:02:32PM +0000, Edward Cree wrote:
> On 11/11/18 20:04, Paul E. McKenney wrote:
> > From: Lance Roy <ldr709@gmail.com>
> >
> > lockdep_assert_held() is better suited to checking locking requirements,
> > since it only checks if the current thread holds the lock regardless of
> > whether someone else does. This is also a step towards possibly removing
> > spin_is_locked().
> >
> > Signed-off-by: Lance Roy <ldr709@gmail.com>
> > Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
> > Cc: Edward Cree <ecree@solarflare.com>
> > Cc: Bert Kenward <bkenward@solarflare.com>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: <netdev@vger.kernel.org>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> > ---
> Acked-by: Edward Cree <ecree@solarflare.com>
Applied, thank you!
Thanx, Paul
> > drivers/net/ethernet/sfc/efx.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
> > index 98fe7e762e17..3643015a55cf 100644
> > --- a/drivers/net/ethernet/sfc/efx.c
> > +++ b/drivers/net/ethernet/sfc/efx.c
> > @@ -3167,7 +3167,7 @@ struct hlist_head *efx_rps_hash_bucket(struct efx_nic *efx,
> > {
> > u32 hash = efx_filter_spec_hash(spec);
> >
> > - WARN_ON(!spin_is_locked(&efx->rps_hash_lock));
> > + lockdep_assert_held(&efx->rps_hash_lock);
> > if (!efx->rps_hash_table)
> > return NULL;
> > return &efx->rps_hash_table[hash % EFX_ARFS_HASH_TABLE_SIZE];
>
>
^ permalink raw reply
* Re: [RFC PATCH 2/6] phy: armada38x: add common phy support
From: Andrew Lunn @ 2018-11-12 17:03 UTC (permalink / raw)
To: Russell King
Cc: devicetree, linux-arm-kernel, netdev, Gregory Clement,
Jason Cooper, Kishon Vijay Abraham I, Mark Rutland, Rob Herring,
Sebastian Hesselbarth, Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <E1gMBMi-00089Q-7S@rmk-PC.armlinux.org.uk>
> +static int a38x_comphy_poll(struct a38x_comphy_lane *lane,
> + unsigned int offset, u32 mask, u32 value)
> +{
> + unsigned int timeout = 10;
> + u32 val;
> +
> + while (1) {
> + val = readl_relaxed(lane->base + offset);
> + if ((val & mask) == value)
> + return 0;
> + if (!timeout--)
> + break;
> + udelay(10);
> + }
Hi Russell
Maybe use one of the readx_poll_timeout() variants?
Andrew
^ permalink raw reply
* Re: [PATCH][net-next] net: remove BUG_ON from __pskb_pull_tail
From: David Miller @ 2018-11-12 16:55 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1542014773-23361-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Mon, 12 Nov 2018 17:26:13 +0800
> do {
> - BUG_ON(!list);
>
Please get rid of the empty line afterwards as well.
Thank you.
^ permalink raw reply
* Re: [PATCH net v2 1/1] bnx2x: Assign unique DMAE channel number for FW DMAE transactions.
From: David Miller @ 2018-11-12 16:54 UTC (permalink / raw)
To: sudarsana.kalluru; +Cc: netdev, Michal.Kalderon
In-Reply-To: <20181112022734.22168-1-sudarsana.kalluru@cavium.com>
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Sun, 11 Nov 2018 18:27:34 -0800
> Driver assigns DMAE channel 0 for FW as part of START_RAMROD command. FW
> uses this channel for DMAE operations (e.g., TIME_SYNC implementation).
> Driver also uses the same channel 0 for DMAE operations for some of the PFs
> (e.g., PF0 on Port0). This could lead to concurrent access to the DMAE
> channel by FW and driver which is not legal. Hence need to assign unique
> DMAE id for FW.
> Currently following DMAE channels are used by the clients,
> MFW - OCBB/OCSD functionality uses DMAE channel 14/15
> Driver 0-3 and 8-11 (for PF dmae operations)
> 4 and 12 (for stats requests)
> Assigning unique dmae_id '13' to the FW.
>
> Changes from previous version:
> ------------------------------
> v2: Incorporated the review comments.
>
> Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
> Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/3] tcp: get rid of tcp_tso_should_defer() dependency on HZ/jiffies
From: Yuchung Cheng @ 2018-11-12 16:52 UTC (permalink / raw)
To: Neal Cardwell
Cc: Eric Dumazet, David Miller, Netdev, Soheil Hassas Yeganeh,
Eric Dumazet
In-Reply-To: <CADVnQy=eHHZdty4sxy_RV6AOKFiA+G2BVoPUjYGM+s6YZRD_JA@mail.gmail.com>
On Sun, Nov 11, 2018 at 11:06 AM, Neal Cardwell <ncardwell@google.com> wrote:
> On Sun, Nov 11, 2018 at 9:41 AM Eric Dumazet <edumazet@google.com> wrote:
>>
>> tcp_tso_should_defer() first heuristic is to not defer
>> if last send is "old enough".
>>
>> Its current implementation uses jiffies and its low granularity.
>>
>> TSO autodefer performance should not rely on kernel HZ :/
>>
>> After EDT conversion, we have state variables in nanoseconds that
>> can allow us to properly implement the heuristic.
>>
>> This patch increases TSO chunk sizes on medium rate flows,
>> especially when receivers do not use GRO or similar aggregation.
>>
>> It also reduces bursts for HZ=100 or HZ=250 kernels, making TCP
>> behavior more uniform.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
>> ---
>
> Nice. Thanks!
>
> Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Love it
>
> neal
^ permalink raw reply
* Re: [PATCH iproute2] testsuite: ss: Fix spacing in expected output for ssfilter.t
From: Stephen Hemminger @ 2018-11-12 16:41 UTC (permalink / raw)
To: Phil Sutter; +Cc: Stefano Brivio, Yoann P., netdev
In-Reply-To: <20181110214844.GL6440@orbyte.nwl.cc>
On Sat, 10 Nov 2018 22:48:44 +0100
Phil Sutter <phil@nwl.cc> wrote:
> Hi Stefano,
>
> On Sat, Nov 10, 2018 at 10:21:59AM +0100, Stefano Brivio wrote:
> > Since commit 00240899ec0b ("ss: Actually print left delimiter for
> > columns") changes spacing in ss output, we also need to adjust for that in
> > the ss filter test.
> >
> > Fixes: 00240899ec0b ("ss: Actually print left delimiter for columns")
> > Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Applied, thanks.
^ permalink raw reply
* [PATCH iproute2] testsuite: colorize test result output
From: Stephen Hemminger @ 2018-11-12 16:39 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
When running testsuite it is easy as a human to miss failure.
Add symbol colorizing to SKIPED/PASS/FAIL output.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
testsuite/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/testsuite/Makefile b/testsuite/Makefile
index b3aebec1517b..2dc7f166c709 100644
--- a/testsuite/Makefile
+++ b/testsuite/Makefile
@@ -85,11 +85,11 @@ endif
TC="$$i/tc/tc" IP="$$i/ip/ip" SS=$$i/misc/ss DEV="$(DEV)" IPVER="$@" SNAME="$$i" \
ERRF="$(RESULTS_DIR)/$@.$$o.err" $(PREFIX) tests/$@ > $(RESULTS_DIR)/$@.$$o.out; \
if [ "$$?" = "127" ]; then \
- echo "SKIPPED"; \
+ echo -e "\e[1;35mSKIPPED\e[0m"; \
elif [ -e "$(RESULTS_DIR)/$@.$$o.err" ]; then \
- echo "FAILED"; \
+ echo -e "\e[0;31mFAILED\e[0m"; \
else \
- echo "PASS"; \
+ echo -e "\e[0;32mPASS\e[0m"; \
fi; \
rm "$$TMP_ERR" "$$TMP_OUT"; \
sudo dmesg > $(RESULTS_DIR)/$@.$$o.dmesg; \
--
2.19.1
^ 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