* [PATCH net] ibmveth: Do not process frames after calling napi_reschedule
From: Thomas Falcon @ 2019-01-24 17:17 UTC (permalink / raw)
To: netdev; +Cc: Thomas Falcon
The IBM virtual ethernet driver's polling function continues
to process frames after rescheduling NAPI, resulting in a warning
if it exhausted its budget. Do not restart polling after calling
napi_reschedule. Instead let frames be processed in the following
instance.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmveth.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
index 098d876..dd71d5d 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -1313,7 +1313,6 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
unsigned long lpar_rc;
u16 mss = 0;
-restart_poll:
while (frames_processed < budget) {
if (!ibmveth_rxq_pending_buffer(adapter))
break;
@@ -1401,7 +1400,6 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
napi_reschedule(napi)) {
lpar_rc = h_vio_signal(adapter->vdev->unit_address,
VIO_IRQ_DISABLE);
- goto restart_poll;
}
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] net: mlx5: allow default ip_proto to offload
From: Or Gerlitz @ 2019-01-24 17:14 UTC (permalink / raw)
To: Tonghao Zhang
Cc: Or Gerlitz, Saeed Mahameed, Leon Romanovsky, Linux Netdev List
In-Reply-To: <CAMDZJNXqC-eW0aaNUP5OGvCUQiYT_C=19H9C2jp9TW=+Z5KgWw@mail.gmail.com>
On Sat, Jan 19, 2019 at 10:50 AM Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
> On Fri, Jan 18, 2019 at 10:19 PM Or Gerlitz <gerlitz.or@gmail.com> wrote:
> > On Thu, Jan 17, 2019 at 3:34 PM Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
> > > On Thu, Jan 17, 2019 at 8:58 PM Or Gerlitz <gerlitz.or@gmail.com> wrote:
> > > > On Thu, Jan 17, 2019 at 11:28 AM <xiangxia.m.yue@gmail.com> wrote:
> > > > > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >
> > > with this patch, run the command [2], we will not get err log,
> > > and the filter work in hw.
> >
> > This whole thing is done for a reason which is the inability of the current HW
> > to adjust checksum/crc for few L3 protocols. Such adjustment is needed if
> > you modify some fields of L3 headers, e.g re-write src/dst IP address.
> I got it, thanks
> > > We should consider ip_proto == 0, in some case, we only
> > > modify dest ip or src ip.
> >
> > we can't let it go without clear matching on the ip protocol, as I explained
> > above. With my proposed patch you will be able to NAT much more protocols
> > (all of them expect for three, and we're working to reduce that), but
> > you still need
> > a tc rule per ip proto
>
>
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> > index 608025ca5c04..affb523e0e35 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> > @@ -2167,11 +2167,11 @@ static bool
> > modify_header_match_supported(struct mlx5_flow_spec *spec,
> > }
> >
> > ip_proto = MLX5_GET(fte_match_set_lyr_2_4, headers_v, ip_protocol);
> > - if (modify_ip_header && ip_proto != IPPROTO_TCP &&
> > - ip_proto != IPPROTO_UDP && ip_proto != IPPROTO_ICMP) {
> > + if (modify_ip_header && (ip_proto == IPPROTO_ICMPV6 ||
> > + ip_proto == IPPROTO_SCTP || ip_proto == IPPROTO_UDPLITE)) {
> > NL_SET_ERR_MSG_MOD(extack,
> > - "can't offload re-write of non TCP/UDP");
> > - pr_info("can't offload re-write of ip proto %d\n", ip_proto);
> > + "can't offload this re-write of IP
> > addresses");
> > + pr_info("can't offload re-write of IP addrs for ip
> > proto %d\n", ip_proto);
> > return false;
> > }
> This patch work for me too, because ip_proto == 0 will not return err(
> and my patch allow ip_proto == 0 and not return err) and will you send
> it to net-next ? because i can't find it in net-next.
basically, I was planning to upstream it on this cycle, but your
comment below is
something I need to look at
> and one question, In your patch, should we check ip_proto is valid ?
> for example, ip_proto == 18, is not valid protocol.
yeah, this becomes a bit ugly, I need to see how to address that
> flower ip_proto 18
^ permalink raw reply
* Re: [PATCH 6/8] power: reset: at91-reset: add support for sam9x60 SoC
From: Sebastian Reichel @ 2019-01-24 17:11 UTC (permalink / raw)
To: Nicolas.Ferre
Cc: alexandre.belloni, Ludovic.Desroches, linux-kernel,
linux-arm-kernel, linux-pm, netdev, davem, linux-usb, stern,
gregkh, robh+dt, devicetree
In-Reply-To: <a74956fc-6085-eec2-c1b8-ed116b2297d8@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]
Hi,
On Thu, Jan 24, 2019 at 10:34:50AM +0000, Nicolas.Ferre@microchip.com wrote:
> Hi Sebastian,
>
> On 23/01/2019 at 19:34, Sebastian Reichel wrote:
> > Hi,
> >
> > On Wed, Jan 16, 2019 at 10:57:42AM +0100, Nicolas Ferre wrote:
> >> Add support for additional reset causes and the proper compatibility
> >> string for sam9x60 SoC. The restart function is the same as the samx7.
> >>
> >> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> >> ---
> >> drivers/power/reset/at91-reset.c | 13 +++++++++++++
> >> 1 file changed, 13 insertions(+)
> >>
> >> diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c
> >> index f44a9ffcc2ab..44ca983a49a1 100644
> >> --- a/drivers/power/reset/at91-reset.c
> >> +++ b/drivers/power/reset/at91-reset.c
> >> @@ -44,6 +44,9 @@ enum reset_type {
> >> RESET_TYPE_WATCHDOG = 2,
> >> RESET_TYPE_SOFTWARE = 3,
> >> RESET_TYPE_USER = 4,
> >> + RESET_TYPE_CPU_FAIL = 6,
> >> + RESET_TYPE_XTAL_FAIL = 7,
> >> + RESET_TYPE_ULP2 = 8,
> >
> > what happened to 5? :)
>
> That a good question ;-)
>
> It's marked as "Reserved"... which opens up a whole new field of
> speculation :-)
Ok :)
> [..]
>
> >> { .compatible = "atmel,samx7-rstc", .data = samx7_restart },
> >> + { .compatible = "microchip,sam9x60-rstc", .data = samx7_restart },
> >> { /* sentinel */ }
> >> };
> >> MODULE_DEVICE_TABLE(of, at91_reset_of_match);
> >
> > Patch looks fine to me. But I will wait a bit with merging, so that
> > Alexandre or Ludovic have a chance to provide feedback.
>
> What about merging this patch with the whole series through the at91
> then arm-soc trees?
It seems to be possible to merge this standalone, but merging
through at91/arm-soc is also fine with me.
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH bpf-next v2] selftests/bpf: suppress readelf stderr when probing for BTF support
From: Stanislav Fomichev @ 2019-01-24 16:54 UTC (permalink / raw)
To: netdev; +Cc: davem, ast, daniel, Stanislav Fomichev
Before:
$ make -s -C tools/testing/selftests/bpf
readelf: Error: Missing knowledge of 32-bit reloc types used in DWARF
sections of machine number 247
readelf: Warning: unable to apply unsupported reloc type 10 to section
.debug_info
readelf: Warning: unable to apply unsupported reloc type 1 to section
.debug_info
readelf: Warning: unable to apply unsupported reloc type 10 to section
.debug_info
After:
$ make -s -C tools/testing/selftests/bpf
v2:
* use llvm-readelf instead of redirecting binutils' readelf stderr to
/dev/null
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/testing/selftests/bpf/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 70229de510f5..1cca5f2567c2 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -95,6 +95,7 @@ $(BPFOBJ): force
CLANG ?= clang
LLC ?= llc
LLVM_OBJCOPY ?= llvm-objcopy
+LLVM_READELF ?= llvm-readelf
BTF_PAHOLE ?= pahole
PROBE := $(shell $(LLC) -march=bpf -mcpu=probe -filetype=null /dev/null 2>&1)
@@ -131,7 +132,7 @@ BTF_PAHOLE_PROBE := $(shell $(BTF_PAHOLE) --help 2>&1 | grep BTF)
BTF_OBJCOPY_PROBE := $(shell $(LLVM_OBJCOPY) --help 2>&1 | grep -i 'usage.*llvm')
BTF_LLVM_PROBE := $(shell echo "int main() { return 0; }" | \
$(CLANG) -target bpf -O2 -g -c -x c - -o ./llvm_btf_verify.o; \
- readelf -S ./llvm_btf_verify.o | grep BTF; \
+ $(LLVM_READELF) -S ./llvm_btf_verify.o | grep BTF; \
/bin/rm -f ./llvm_btf_verify.o)
ifneq ($(BTF_LLVM_PROBE),)
--
2.20.1.321.g9e740568ce-goog
^ permalink raw reply related
* [PATCH bpf-next v2 3/3] selftests/bpf: add simple BPF_PROG_TEST_RUN examples for flow dissector
From: Stanislav Fomichev @ 2019-01-24 16:49 UTC (permalink / raw)
To: netdev; +Cc: davem, ast, daniel, Stanislav Fomichev
In-Reply-To: <20190124164953.29740-1-sdf@google.com>
Use existing pkt_v4 and pkt_v6 to make sure flow_keys are what we want.
Also, add new bpf_flow_load routine (and flow_dissector_load.h header)
that loads bpf_flow.o program and does all required setup.
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/testing/selftests/bpf/Makefile | 3 +
.../selftests/bpf/flow_dissector_load.c | 43 ++--------
.../selftests/bpf/flow_dissector_load.h | 55 +++++++++++++
tools/testing/selftests/bpf/test_progs.c | 78 ++++++++++++++++++-
4 files changed, 139 insertions(+), 40 deletions(-)
create mode 100644 tools/testing/selftests/bpf/flow_dissector_load.h
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 70229de510f5..ade67470a152 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -19,6 +19,9 @@ all: $(TEST_CUSTOM_PROGS)
$(TEST_CUSTOM_PROGS): $(OUTPUT)/%: %.c
$(CC) -o $(TEST_CUSTOM_PROGS) -static $< -Wl,--build-id
+flow_dissector_load.c: flow_dissector_load.h
+test_run.c: flow_dissector_load.h
+
# Order correspond to 'make run_tests' order
TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test_progs \
test_align test_verifier_log test_dev_cgroup test_tcpbpf_user \
diff --git a/tools/testing/selftests/bpf/flow_dissector_load.c b/tools/testing/selftests/bpf/flow_dissector_load.c
index ae8180b11d5f..77cafa66d048 100644
--- a/tools/testing/selftests/bpf/flow_dissector_load.c
+++ b/tools/testing/selftests/bpf/flow_dissector_load.c
@@ -12,6 +12,7 @@
#include <bpf/libbpf.h>
#include "bpf_rlimit.h"
+#include "flow_dissector_load.h"
const char *cfg_pin_path = "/sys/fs/bpf/flow_dissector";
const char *cfg_map_name = "jmp_table";
@@ -21,46 +22,13 @@ char *cfg_path_name;
static void load_and_attach_program(void)
{
- struct bpf_program *prog, *main_prog;
- struct bpf_map *prog_array;
- int i, fd, prog_fd, ret;
+ int prog_fd, ret;
struct bpf_object *obj;
- int prog_array_fd;
- ret = bpf_prog_load(cfg_path_name, BPF_PROG_TYPE_FLOW_DISSECTOR, &obj,
- &prog_fd);
+ ret = bpf_flow_load(&obj, cfg_path_name, cfg_section_name,
+ cfg_map_name, &prog_fd);
if (ret)
- error(1, 0, "bpf_prog_load %s", cfg_path_name);
-
- main_prog = bpf_object__find_program_by_title(obj, cfg_section_name);
- if (!main_prog)
- error(1, 0, "bpf_object__find_program_by_title %s",
- cfg_section_name);
-
- prog_fd = bpf_program__fd(main_prog);
- if (prog_fd < 0)
- error(1, 0, "bpf_program__fd");
-
- prog_array = bpf_object__find_map_by_name(obj, cfg_map_name);
- if (!prog_array)
- error(1, 0, "bpf_object__find_map_by_name %s", cfg_map_name);
-
- prog_array_fd = bpf_map__fd(prog_array);
- if (prog_array_fd < 0)
- error(1, 0, "bpf_map__fd %s", cfg_map_name);
-
- i = 0;
- bpf_object__for_each_program(prog, obj) {
- fd = bpf_program__fd(prog);
- if (fd < 0)
- error(1, 0, "bpf_program__fd");
-
- if (fd != prog_fd) {
- printf("%d: %s\n", i, bpf_program__title(prog, false));
- bpf_map_update_elem(prog_array_fd, &i, &fd, BPF_ANY);
- ++i;
- }
- }
+ error(1, 0, "bpf_flow_load %s", cfg_path_name);
ret = bpf_prog_attach(prog_fd, 0 /* Ignore */, BPF_FLOW_DISSECTOR, 0);
if (ret)
@@ -69,7 +37,6 @@ static void load_and_attach_program(void)
ret = bpf_object__pin(obj, cfg_pin_path);
if (ret)
error(1, 0, "bpf_object__pin %s", cfg_pin_path);
-
}
static void detach_program(void)
diff --git a/tools/testing/selftests/bpf/flow_dissector_load.h b/tools/testing/selftests/bpf/flow_dissector_load.h
new file mode 100644
index 000000000000..41dd6959feb0
--- /dev/null
+++ b/tools/testing/selftests/bpf/flow_dissector_load.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+#ifndef FLOW_DISSECTOR_LOAD
+#define FLOW_DISSECTOR_LOAD
+
+#include <bpf/bpf.h>
+#include <bpf/libbpf.h>
+
+static inline int bpf_flow_load(struct bpf_object **obj,
+ const char *path,
+ const char *section_name,
+ const char *map_name,
+ int *prog_fd)
+{
+ struct bpf_program *prog, *main_prog;
+ struct bpf_map *prog_array;
+ int prog_array_fd;
+ int ret, fd, i;
+
+ ret = bpf_prog_load(path, BPF_PROG_TYPE_FLOW_DISSECTOR, obj,
+ prog_fd);
+ if (ret)
+ return ret;
+
+ main_prog = bpf_object__find_program_by_title(*obj, section_name);
+ if (!main_prog)
+ return ret;
+
+ *prog_fd = bpf_program__fd(main_prog);
+ if (*prog_fd < 0)
+ return ret;
+
+ prog_array = bpf_object__find_map_by_name(*obj, map_name);
+ if (!prog_array)
+ return ret;
+
+ prog_array_fd = bpf_map__fd(prog_array);
+ if (prog_array_fd < 0)
+ return ret;
+
+ i = 0;
+ bpf_object__for_each_program(prog, *obj) {
+ fd = bpf_program__fd(prog);
+ if (fd < 0)
+ return fd;
+
+ if (fd != *prog_fd) {
+ bpf_map_update_elem(prog_array_fd, &i, &fd, BPF_ANY);
+ ++i;
+ }
+ }
+
+ return 0;
+}
+
+#endif /* FLOW_DISSECTOR_LOAD */
diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c
index 126fc624290d..5f46680d4ad4 100644
--- a/tools/testing/selftests/bpf/test_progs.c
+++ b/tools/testing/selftests/bpf/test_progs.c
@@ -39,6 +39,7 @@ typedef __u16 __sum16;
#include "bpf_endian.h"
#include "bpf_rlimit.h"
#include "trace_helpers.h"
+#include "flow_dissector_load.h"
static int error_cnt, pass_cnt;
static bool jit_enabled;
@@ -53,9 +54,10 @@ static struct {
} __packed pkt_v4 = {
.eth.h_proto = __bpf_constant_htons(ETH_P_IP),
.iph.ihl = 5,
- .iph.protocol = 6,
+ .iph.protocol = IPPROTO_TCP,
.iph.tot_len = __bpf_constant_htons(MAGIC_BYTES),
.tcp.urg_ptr = 123,
+ .tcp.doff = 5,
};
/* ipv6 test vector */
@@ -65,9 +67,10 @@ static struct {
struct tcphdr tcp;
} __packed pkt_v6 = {
.eth.h_proto = __bpf_constant_htons(ETH_P_IPV6),
- .iph.nexthdr = 6,
+ .iph.nexthdr = IPPROTO_TCP,
.iph.payload_len = __bpf_constant_htons(MAGIC_BYTES),
.tcp.urg_ptr = 123,
+ .tcp.doff = 5,
};
#define _CHECK(condition, tag, duration, format...) ({ \
@@ -1882,6 +1885,76 @@ static void test_queue_stack_map(int type)
bpf_object__close(obj);
}
+#define CHECK_FLOW_KEYS(desc, got, expected) \
+ CHECK(memcmp(&got, &expected, sizeof(got)) != 0, \
+ desc, \
+ "nhoff=%u/%u " \
+ "thoff=%u/%u " \
+ "addr_proto=0x%x/0x%x " \
+ "is_frag=%u/%u " \
+ "is_first_frag=%u/%u " \
+ "is_encap=%u/%u " \
+ "n_proto=0x%x/0x%x " \
+ "sport=%u/%u " \
+ "dport=%u/%u\n", \
+ got.nhoff, expected.nhoff, \
+ got.thoff, expected.thoff, \
+ got.addr_proto, expected.addr_proto, \
+ got.is_frag, expected.is_frag, \
+ got.is_first_frag, expected.is_first_frag, \
+ got.is_encap, expected.is_encap, \
+ got.n_proto, expected.n_proto, \
+ got.sport, expected.sport, \
+ got.dport, expected.dport)
+
+static struct bpf_flow_keys pkt_v4_flow_keys = {
+ .nhoff = 0,
+ .thoff = sizeof(struct iphdr),
+ .addr_proto = ETH_P_IP,
+ .ip_proto = IPPROTO_TCP,
+ .n_proto = bpf_htons(ETH_P_IP),
+};
+
+static struct bpf_flow_keys pkt_v6_flow_keys = {
+ .nhoff = 0,
+ .thoff = sizeof(struct ipv6hdr),
+ .addr_proto = ETH_P_IPV6,
+ .ip_proto = IPPROTO_TCP,
+ .n_proto = bpf_htons(ETH_P_IPV6),
+};
+
+static void test_flow_dissector(void)
+{
+ struct bpf_flow_keys flow_keys;
+ struct bpf_object *obj;
+ __u32 duration, retval;
+ int err, prog_fd;
+ __u32 size;
+
+ err = bpf_flow_load(&obj, "./bpf_flow.o", "flow_dissector",
+ "jmp_table", &prog_fd);
+ if (err) {
+ error_cnt++;
+ return;
+ }
+
+ err = bpf_prog_test_run(prog_fd, 10, &pkt_v4, sizeof(pkt_v4),
+ &flow_keys, &size, &retval, &duration);
+ CHECK(size != sizeof(flow_keys) || err || retval != 1, "ipv4",
+ "err %d errno %d retval %d duration %d size %u/%lu\n",
+ err, errno, retval, duration, size, sizeof(flow_keys));
+ CHECK_FLOW_KEYS("ipv4_flow_keys", flow_keys, pkt_v4_flow_keys);
+
+ err = bpf_prog_test_run(prog_fd, 10, &pkt_v6, sizeof(pkt_v6),
+ &flow_keys, &size, &retval, &duration);
+ CHECK(size != sizeof(flow_keys) || err || retval != 1, "ipv6",
+ "err %d errno %d retval %d duration %d size %u/%lu\n",
+ err, errno, retval, duration, size, sizeof(flow_keys));
+ CHECK_FLOW_KEYS("ipv6_flow_keys", flow_keys, pkt_v6_flow_keys);
+
+ bpf_object__close(obj);
+}
+
int main(void)
{
srand(time(NULL));
@@ -1909,6 +1982,7 @@ int main(void)
test_reference_tracking();
test_queue_stack_map(QUEUE);
test_queue_stack_map(STACK);
+ test_flow_dissector();
printf("Summary: %d PASSED, %d FAILED\n", pass_cnt, error_cnt);
return error_cnt ? EXIT_FAILURE : EXIT_SUCCESS;
--
2.20.1.321.g9e740568ce-goog
^ permalink raw reply related
* [PATCH bpf-next v2 2/3] bpf: add BPF_PROG_TEST_RUN support for flow dissector
From: Stanislav Fomichev @ 2019-01-24 16:49 UTC (permalink / raw)
To: netdev; +Cc: davem, ast, daniel, Stanislav Fomichev
In-Reply-To: <20190124164953.29740-1-sdf@google.com>
The input is packet data, the output is struct bpf_flow_key. This should
make it easy to test flow dissector programs without elaborate
setup.
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
include/linux/bpf.h | 3 ++
net/bpf/test_run.c | 82 +++++++++++++++++++++++++++++++++++++++++++++
net/core/filter.c | 1 +
3 files changed, 86 insertions(+)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index e734f163bd0b..701ef954a258 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -397,6 +397,9 @@ int bpf_prog_test_run_xdp(struct bpf_prog *prog, const union bpf_attr *kattr,
union bpf_attr __user *uattr);
int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
union bpf_attr __user *uattr);
+int bpf_prog_test_run_flow_dissector(struct bpf_prog *prog,
+ const union bpf_attr *kattr,
+ union bpf_attr __user *uattr);
/* an array of programs to be executed under rcu_lock.
*
diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
index fa2644d276ef..2c5172b33209 100644
--- a/net/bpf/test_run.c
+++ b/net/bpf/test_run.c
@@ -240,3 +240,85 @@ int bpf_prog_test_run_xdp(struct bpf_prog *prog, const union bpf_attr *kattr,
kfree(data);
return ret;
}
+
+int bpf_prog_test_run_flow_dissector(struct bpf_prog *prog,
+ const union bpf_attr *kattr,
+ union bpf_attr __user *uattr)
+{
+ u32 size = kattr->test.data_size_in;
+ u32 repeat = kattr->test.repeat;
+ struct bpf_flow_keys flow_keys;
+ u64 time_start, time_spent = 0;
+ struct bpf_skb_data_end *cb;
+ u32 retval, duration;
+ struct sk_buff *skb;
+ struct sock *sk;
+ void *data;
+ int ret;
+ u32 i;
+
+ if (prog->type != BPF_PROG_TYPE_FLOW_DISSECTOR)
+ return -EINVAL;
+
+ data = bpf_test_init(kattr, size, NET_SKB_PAD + NET_IP_ALIGN,
+ SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ sk = kzalloc(sizeof(*sk), GFP_USER);
+ if (!sk) {
+ kfree(data);
+ return -ENOMEM;
+ }
+ sock_net_set(sk, current->nsproxy->net_ns);
+ sock_init_data(NULL, sk);
+
+ skb = build_skb(data, 0);
+ if (!skb) {
+ kfree(data);
+ kfree(sk);
+ return -ENOMEM;
+ }
+ skb->sk = sk;
+
+ skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
+ __skb_put(skb, size);
+ skb->protocol = eth_type_trans(skb,
+ current->nsproxy->net_ns->loopback_dev);
+ skb_reset_network_header(skb);
+
+ cb = (struct bpf_skb_data_end *)skb->cb;
+ cb->qdisc_cb.flow_keys = &flow_keys;
+
+ if (!repeat)
+ repeat = 1;
+
+ time_start = ktime_get_ns();
+ for (i = 0; i < repeat; i++) {
+ preempt_disable();
+ rcu_read_lock();
+ retval = __skb_flow_bpf_dissect(prog, skb,
+ &flow_keys_dissector,
+ &flow_keys);
+ rcu_read_unlock();
+ preempt_enable();
+
+ if (need_resched()) {
+ if (signal_pending(current))
+ break;
+ time_spent += ktime_get_ns() - time_start;
+ cond_resched();
+ time_start = ktime_get_ns();
+ }
+ }
+ time_spent += ktime_get_ns() - time_start;
+ do_div(time_spent, repeat);
+ duration = time_spent > U32_MAX ? U32_MAX : (u32)time_spent;
+
+ ret = bpf_test_finish(kattr, uattr, &flow_keys, sizeof(flow_keys),
+ retval, duration);
+
+ kfree_skb(skb);
+ kfree(sk);
+ return ret;
+}
diff --git a/net/core/filter.c b/net/core/filter.c
index 2b3b436ef545..ff4641dae2be 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -7690,6 +7690,7 @@ const struct bpf_verifier_ops flow_dissector_verifier_ops = {
};
const struct bpf_prog_ops flow_dissector_prog_ops = {
+ .test_run = bpf_prog_test_run_flow_dissector,
};
int sk_detach_filter(struct sock *sk)
--
2.20.1.321.g9e740568ce-goog
^ permalink raw reply related
* [PATCH bpf-next v2 1/3] net/flow_dissector: move bpf case into __skb_flow_bpf_dissect
From: Stanislav Fomichev @ 2019-01-24 16:49 UTC (permalink / raw)
To: netdev; +Cc: davem, ast, daniel, Stanislav Fomichev
In-Reply-To: <20190124164953.29740-1-sdf@google.com>
This way, we can reuse it for flow dissector in BPF_PROG_TEST_RUN.
No functional changes.
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
include/linux/skbuff.h | 5 +++
net/core/flow_dissector.c | 92 +++++++++++++++++++++++----------------
2 files changed, 59 insertions(+), 38 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 93f56fddd92a..be762fc34ff3 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1221,6 +1221,11 @@ static inline int skb_flow_dissector_bpf_prog_detach(const union bpf_attr *attr)
}
#endif
+struct bpf_flow_keys;
+bool __skb_flow_bpf_dissect(struct bpf_prog *prog,
+ const struct sk_buff *skb,
+ struct flow_dissector *flow_dissector,
+ struct bpf_flow_keys *flow_keys);
bool __skb_flow_dissect(const struct sk_buff *skb,
struct flow_dissector *flow_dissector,
void *target_container,
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 9f2840510e63..bb1a54747d64 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -683,6 +683,46 @@ static void __skb_flow_bpf_to_target(const struct bpf_flow_keys *flow_keys,
}
}
+bool __skb_flow_bpf_dissect(struct bpf_prog *prog,
+ const struct sk_buff *skb,
+ struct flow_dissector *flow_dissector,
+ struct bpf_flow_keys *flow_keys)
+{
+ struct bpf_skb_data_end cb_saved;
+ struct bpf_skb_data_end *cb;
+ u32 result;
+
+ /* Note that even though the const qualifier is discarded
+ * throughout the execution of the BPF program, all changes(the
+ * control block) are reverted after the BPF program returns.
+ * Therefore, __skb_flow_dissect does not alter the skb.
+ */
+
+ cb = (struct bpf_skb_data_end *)skb->cb;
+
+ /* Save Control Block */
+ memcpy(&cb_saved, cb, sizeof(cb_saved));
+ memset(cb, 0, sizeof(*cb));
+
+ /* Pass parameters to the BPF program */
+ memset(flow_keys, 0, sizeof(*flow_keys));
+ cb->qdisc_cb.flow_keys = flow_keys;
+ flow_keys->nhoff = skb_network_offset(skb);
+ flow_keys->thoff = flow_keys->nhoff;
+
+ bpf_compute_data_pointers((struct sk_buff *)skb);
+ result = BPF_PROG_RUN(prog, skb);
+
+ /* Restore state */
+ memcpy(cb, &cb_saved, sizeof(cb_saved));
+
+ flow_keys->nhoff = clamp_t(u16, flow_keys->nhoff, 0, skb->len);
+ flow_keys->thoff = clamp_t(u16, flow_keys->thoff,
+ flow_keys->nhoff, skb->len);
+
+ return result == BPF_OK;
+}
+
/**
* __skb_flow_dissect - extract the flow_keys struct and return it
* @skb: sk_buff to extract the flow from, can be NULL if the rest are specified
@@ -714,7 +754,6 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
struct flow_dissector_key_vlan *key_vlan;
enum flow_dissect_ret fdret;
enum flow_dissector_key_id dissector_vlan = FLOW_DISSECTOR_KEY_MAX;
- struct bpf_prog *attached = NULL;
int num_hdrs = 0;
u8 ip_proto = 0;
bool ret;
@@ -754,53 +793,30 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
FLOW_DISSECTOR_KEY_BASIC,
target_container);
- rcu_read_lock();
if (skb) {
+ struct bpf_flow_keys flow_keys;
+ struct bpf_prog *attached = NULL;
+
+ rcu_read_lock();
+
if (skb->dev)
attached = rcu_dereference(dev_net(skb->dev)->flow_dissector_prog);
else if (skb->sk)
attached = rcu_dereference(sock_net(skb->sk)->flow_dissector_prog);
else
WARN_ON_ONCE(1);
- }
- if (attached) {
- /* Note that even though the const qualifier is discarded
- * throughout the execution of the BPF program, all changes(the
- * control block) are reverted after the BPF program returns.
- * Therefore, __skb_flow_dissect does not alter the skb.
- */
- struct bpf_flow_keys flow_keys = {};
- struct bpf_skb_data_end cb_saved;
- struct bpf_skb_data_end *cb;
- u32 result;
-
- cb = (struct bpf_skb_data_end *)skb->cb;
-
- /* Save Control Block */
- memcpy(&cb_saved, cb, sizeof(cb_saved));
- memset(cb, 0, sizeof(cb_saved));
- /* Pass parameters to the BPF program */
- cb->qdisc_cb.flow_keys = &flow_keys;
- flow_keys.nhoff = nhoff;
- flow_keys.thoff = nhoff;
-
- bpf_compute_data_pointers((struct sk_buff *)skb);
- result = BPF_PROG_RUN(attached, skb);
-
- /* Restore state */
- memcpy(cb, &cb_saved, sizeof(cb_saved));
-
- flow_keys.nhoff = clamp_t(u16, flow_keys.nhoff, 0, skb->len);
- flow_keys.thoff = clamp_t(u16, flow_keys.thoff,
- flow_keys.nhoff, skb->len);
-
- __skb_flow_bpf_to_target(&flow_keys, flow_dissector,
- target_container);
+ if (attached) {
+ ret = __skb_flow_bpf_dissect(attached, skb,
+ flow_dissector,
+ &flow_keys);
+ __skb_flow_bpf_to_target(&flow_keys, flow_dissector,
+ target_container);
+ rcu_read_unlock();
+ return ret;
+ }
rcu_read_unlock();
- return result == BPF_OK;
}
- rcu_read_unlock();
if (dissector_uses_key(flow_dissector,
FLOW_DISSECTOR_KEY_ETH_ADDRS)) {
--
2.20.1.321.g9e740568ce-goog
^ permalink raw reply related
* [PATCH bpf-next v2 0/3] support flow dissector in BPF_PROG_TEST_RUN
From: Stanislav Fomichev @ 2019-01-24 16:49 UTC (permalink / raw)
To: netdev; +Cc: davem, ast, daniel, Stanislav Fomichev
This patch series adds support for testing flow dissector BPF programs by
extending already existing BPF_PROG_TEST_RUN. The goal is to have a
packet as an input and `struct bpf_flow_key' as an output. That way
we can easily test flow dissector programs' behavior.
I've also modified existing test_progs.c test to do a simple flow
dissector run as well.
* first patch introduces new __skb_flow_bpf_dissect to simplify
sharing between __skb_flow_bpf_dissect and BPF_PROG_TEST_RUN
* second patch adds actual BPF_PROG_TEST_RUN support
* third patch adds example usage to the selftests
v2:
* loop over 'kattr->test.repeat' inside of
bpf_prog_test_run_flow_dissector, don't reuse
bpf_test_run/bpf_test_run_one
Stanislav Fomichev (3):
net/flow_dissector: move bpf case into __skb_flow_bpf_dissect
bpf: add BPF_PROG_TEST_RUN support for flow dissector
selftests/bpf: add simple BPF_PROG_TEST_RUN examples for flow
dissector
include/linux/bpf.h | 3 +
include/linux/skbuff.h | 5 +
net/bpf/test_run.c | 82 +++++++++++++++++
net/core/filter.c | 1 +
net/core/flow_dissector.c | 92 +++++++++++--------
tools/testing/selftests/bpf/Makefile | 3 +
.../selftests/bpf/flow_dissector_load.c | 43 +--------
.../selftests/bpf/flow_dissector_load.h | 55 +++++++++++
tools/testing/selftests/bpf/test_progs.c | 78 +++++++++++++++-
9 files changed, 284 insertions(+), 78 deletions(-)
create mode 100644 tools/testing/selftests/bpf/flow_dissector_load.h
--
2.20.1.321.g9e740568ce-goog
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] net/mlx5e: Update hw flows when encap source mac changed
From: Or Gerlitz @ 2019-01-24 16:48 UTC (permalink / raw)
To: Tonghao Zhang; +Cc: Saeed Mahameed, Linux Netdev List, Hadar Hen Zion
In-Reply-To: <1548156126-8021-1-git-send-email-xiangxia.m.yue@gmail.com>
On Tue, Jan 22, 2019 at 4:38 PM <xiangxia.m.yue@gmail.com> wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> When we offload tc filters to hardware, hardware flows can
> be updated when mac of encap destination ip is changed.
> But we ignore one case, that the mac of local encap ip can
> be changed too, so we should also update them.
>
> To fix it, add route_dev in mlx5e_encap_entry struct to save
> the local encap netdevice, and when mac changed, kernel will
> flush all the neighbour on the netdevice and send NETEVENT_NEIGH_UPDATE
> event. The mlx5 driver will delete the flows and add them when neighbour
> available again.
>
> Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
> Cc: Hadar Hen Zion <hadarh@mellanox.com>
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
LGTM
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v1 1/2] net: dsa: mv88e6xxx: Default CMODE to 1000BaseX only on 6390X
From: Andrew Lunn @ 2019-01-24 16:48 UTC (permalink / raw)
To: Marek Behun; +Cc: netdev, Florian Fainelli, David Miller
In-Reply-To: <20190124172916.66e15b29@nic.cz>
> yes, I wanted to set the cpu port mode in DTS at first, but if I
> understood the code correctly (maybe I made a mistake), the CPU port
> mode is not determined from DTS (since there is no phy). Am I wrong?
It should work. I have boards which use it for DSA ports. I'm not sure
i have a board with it for a CPU port though.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: IP defrag: use rbtrees in IPv6 defragmentation
From: Eric Dumazet @ 2019-01-24 16:41 UTC (permalink / raw)
To: Peter Oskolkov, David Miller, netdev; +Cc: Peter Oskolkov
In-Reply-To: <20190122180253.128336-1-posk@google.com>
On 01/22/2019 10:02 AM, Peter Oskolkov wrote:
> Currently, IPv6 defragmentation code drops non-last fragments that
> are smaller than 1280 bytes: see
> commit 0ed4229b08c1 ("ipv6: defrag: drop non-last frags smaller than min mtu")
>
> This behavior is not specified in IPv6 RFCs and appears to break compatibility
> with some IPv6 implementations, as reported here:
> https://www.spinics.net/lists/netdev/msg543846.html
>
> This patchset contains four patches:
> - patch 1 moves rbtree-related code from IPv4 to files shared b/w
> IPv4/IPv6
> - patch 2 changes IPv6 defragmenation code to use rbtrees for defrag
> queue
> - patch 3 changes nf_conntrack IPv6 defragmentation code to use rbtrees
> - patch 4 changes ip_defrag selftest to test changes made in the
> previous three patches.
>
> Along the way, the 1280-byte restrictions are removed.
Thanks a lot for following up on this Peter.
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next 0/2] tcp_bbr: Improving TCP BBR performance for WiFi and cellular networks
From: Eric Dumazet @ 2019-01-24 16:36 UTC (permalink / raw)
To: Priyaranjan Jha, David Miller; +Cc: netdev
In-Reply-To: <20190123200454.260121-1-priyarjha@google.com>
On 01/23/2019 12:04 PM, Priyaranjan Jha wrote:
> Ack aggregation is quite prevalent with wifi, cellular and cable modem
> link tchnologies, ACK decimation in middleboxes, and common offloading
> techniques such as TSO and GRO, at end hosts. Previously, BBR was often
> cwnd-limited in the presence of severe ACK aggregation, which resulted in
> low throughput due to insufficient data in flight.
>
> To achieve good throughput for wifi and other paths with aggregation, this
> patch series implements an ACK aggregation estimator for BBR, which
> estimates the maximum recent degree of ACK aggregation and adapts cwnd
> based on it. The algorithm is further described by the following
> presentation:
> https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00
>
> (1) A preparatory patch, which refactors bbr_target_cwnd for generic
> inflight provisioning.
>
> (2) Implements BBR ack aggregation estimator and adapts cwnd based
> on measured degree of ACK aggregation.
>
> Priyaranjan Jha (2):
> tcp_bbr: refactor bbr_target_cwnd() for general inflight provisioning
> tcp_bbr: adapt cwnd based on ack aggregation estimation
>
> include/net/inet_connection_sock.h | 4 +-
> net/ipv4/tcp_bbr.c | 180 +++++++++++++++++++++++++----
> 2 files changed, 161 insertions(+), 23 deletions(-)
>
Very nice work Priyaranjan
Thanks !
Signed-off-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Want to start it?
From: Denna @ 2019-01-24 8:01 UTC (permalink / raw)
To: netdev
Please let me know the status of your photos, waiting to retouching them.
Do your photos need white background? sharpen? retouching? We can do it for
you.
Send us the test photos today and we can start to work on them.
Thanks,
Denna
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: add BPF_PROG_TEST_RUN support for flow dissector
From: Stanislav Fomichev @ 2019-01-24 16:34 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Stanislav Fomichev, netdev, davem, ast, daniel
In-Reply-To: <20190124035600.ag4d7glkyysiluuu@ast-mbp.dhcp.thefacebook.com>
On 01/23, Alexei Starovoitov wrote:
> On Tue, Jan 22, 2019 at 01:23:14PM -0800, Stanislav Fomichev wrote:
> > The input is packet data, the output is struct bpf_flow_key. This should
> > make it easy to test flow dissector programs without elaborate
> > setup.
> >
> > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > ---
> > include/linux/bpf.h | 3 ++
> > net/bpf/test_run.c | 75 ++++++++++++++++++++++++++++++++++++++++++++-
> > net/core/filter.c | 1 +
> > 3 files changed, 78 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index e734f163bd0b..701ef954a258 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -397,6 +397,9 @@ int bpf_prog_test_run_xdp(struct bpf_prog *prog, const union bpf_attr *kattr,
> > union bpf_attr __user *uattr);
> > int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
> > union bpf_attr __user *uattr);
> > +int bpf_prog_test_run_flow_dissector(struct bpf_prog *prog,
> > + const union bpf_attr *kattr,
> > + union bpf_attr __user *uattr);
> >
> > /* an array of programs to be executed under rcu_lock.
> > *
> > diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
> > index fa2644d276ef..ecad72885f23 100644
> > --- a/net/bpf/test_run.c
> > +++ b/net/bpf/test_run.c
> > @@ -16,12 +16,26 @@
> > static __always_inline u32 bpf_test_run_one(struct bpf_prog *prog, void *ctx,
> > struct bpf_cgroup_storage *storage[MAX_BPF_CGROUP_STORAGE_TYPE])
> > {
> > + struct bpf_skb_data_end *cb;
> > + struct sk_buff *skb;
> > u32 ret;
> >
> > preempt_disable();
> > rcu_read_lock();
> > bpf_cgroup_storage_set(storage);
> > - ret = BPF_PROG_RUN(prog, ctx);
> > +
> > + switch (prog->type) {
> > + case BPF_PROG_TYPE_FLOW_DISSECTOR:
> > + skb = (struct sk_buff *)ctx;
> > + cb = (struct bpf_skb_data_end *)skb->cb;
> > + ret = __skb_flow_bpf_dissect(prog, ctx, &flow_keys_dissector,
> > + cb->qdisc_cb.flow_keys);
> > + break;
> > + default:
> > + ret = BPF_PROG_RUN(prog, ctx);
> > + break;
> > + }
>
> What is the benefit of this minimal code reuse?
> It seems to me bpf_test_run_one() gets slower for all,
> since prog type needs to be checked before every prog run.
> The point of bpf_prog_ops->test_run was to avoid this overhead.
> Are you somehow expecting flow_dissector prog using cgroup local storage?
> I don't think that's possible.
Agreed. Initially I didn't want to re-implement the logic of
bpf_test_run. But now that you mention that it's mostly about cgroup local
storage, I think I can do a simple loop inside of
bpf_prog_test_run_flow_dissector. Thanks, will follow up with another
series!
^ permalink raw reply
* Re: [PATCH net-next v1 1/2] net: dsa: mv88e6xxx: Default CMODE to 1000BaseX only on 6390X
From: Marek Behun @ 2019-01-24 16:29 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli, David Miller
In-Reply-To: <20190124161147.GG482@lunn.ch>
> Hi Marek
>
> Although the previous behaviour might of allowed the cmode to be NA,
> i'm not sure that is a good idea. How do you know the port actually is
> using 2500BaseX, and not SGMII for example?
>
> You really should set the interface mode in the device tree file, so
> you know it does have the value you want.
>
> Andrew
Hi Andrew,
yes, I wanted to set the cpu port mode in DTS at first, but if I
understood the code correctly (maybe I made a mistake), the CPU port
mode is not determined from DTS (since there is no phy). Am I wrong?
It would be better if it was forced from DTS from the CPU port node.
On Turris Mox the mode is set by pin configuration after reset.
Marek
^ permalink raw reply
* [PATCH] qede: Don't implicitly cast enumerated types in __qede_probe
From: Nathan Chancellor @ 2019-01-24 16:27 UTC (permalink / raw)
To: Ariel Elior, everest-linux-l2, David S. Miller
Cc: Tomer Tayar, Michal Kalderon, netdev, linux-kernel,
Nathan Chancellor
Clang warns:
drivers/net/ethernet/qlogic/qede/qede_main.c:1183:29: warning: implicit
conversion from enumeration type 'enum qede_rdma_probe_mode' to
different enumeration type 'enum qede_rdma_remove_mode'
[-Wenum-conversion]
qede_rdma_dev_remove(edev, QEDE_RDMA_PROBE_MODE(mode));
~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/qlogic/qede/qede_main.c:1074:33: note: expanded
from macro 'QEDE_RDMA_PROBE_MODE'
((mode) == QEDE_PROBE_NORMAL ? QEDE_RDMA_PROBE_NORMAL \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/qlogic/qede/qede_main.c:1183:29: warning: implicit
conversion from enumeration type 'enum qede_rdma_probe_mode' to
different enumeration type 'enum qede_rdma_remove_mode'
[-Wenum-conversion]
qede_rdma_dev_remove(edev, QEDE_RDMA_PROBE_MODE(mode));
~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/qlogic/qede/qede_main.c:1075:12: note: expanded
from macro 'QEDE_RDMA_PROBE_MODE'
: QEDE_RDMA_PROBE_RECOVERY)
^~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.
qede_rdma_dev_remove expects an value from enumerated type
qede_rdma_remove_mode. Hoist the definitions of qede_remove_mode
and QEDE_RDMA_REMOVE_MODE up above __qede_probe so they can be
used there, eliminating this warning.
Fixes: 278396de78a9 ("qede: Error recovery process")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/ethernet/qlogic/qede/qede_main.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index de955f2b2980..06bdba90d521 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -1074,6 +1074,15 @@ enum qede_probe_mode {
((mode) == QEDE_PROBE_NORMAL ? QEDE_RDMA_PROBE_NORMAL \
: QEDE_RDMA_PROBE_RECOVERY)
+enum qede_remove_mode {
+ QEDE_REMOVE_NORMAL,
+ QEDE_REMOVE_RECOVERY,
+};
+
+#define QEDE_RDMA_REMOVE_MODE(mode) \
+ ((mode) == QEDE_REMOVE_NORMAL ? QEDE_RDMA_REMOVE_NORMAL \
+ : QEDE_RDMA_REMOVE_RECOVERY)
+
static int __qede_probe(struct pci_dev *pdev, u32 dp_module, u8 dp_level,
bool is_vf, enum qede_probe_mode mode)
{
@@ -1180,7 +1189,7 @@ static int __qede_probe(struct pci_dev *pdev, u32 dp_module, u8 dp_level,
return 0;
err4:
- qede_rdma_dev_remove(edev, QEDE_RDMA_PROBE_MODE(mode));
+ qede_rdma_dev_remove(edev, QEDE_RDMA_REMOVE_MODE(mode));
err3:
free_netdev(edev->ndev);
err2:
@@ -1214,15 +1223,6 @@ static int qede_probe(struct pci_dev *pdev, const struct pci_device_id *id)
QEDE_PROBE_NORMAL);
}
-enum qede_remove_mode {
- QEDE_REMOVE_NORMAL,
- QEDE_REMOVE_RECOVERY,
-};
-
-#define QEDE_RDMA_REMOVE_MODE(mode) \
- ((mode) == QEDE_REMOVE_NORMAL ? QEDE_RDMA_REMOVE_NORMAL \
- : QEDE_RDMA_REMOVE_RECOVERY)
-
static void __qede_remove(struct pci_dev *pdev, enum qede_remove_mode mode)
{
struct net_device *ndev = pci_get_drvdata(pdev);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net] net: mvpp2: fix condition for setting up link interrupt
From: Russell King - ARM Linux admin @ 2019-01-24 16:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Thomas Bogendoerfer, antoine.tenart, maxime.chevallier,
David S. Miller, netdev, linux-kernel
In-Reply-To: <20190124161535.GH482@lunn.ch>
On Thu, Jan 24, 2019 at 05:15:35PM +0100, Andrew Lunn wrote:
> On Thu, Jan 24, 2019 at 04:07:41PM +0000, Russell King - ARM Linux admin wrote:
> > On Thu, Jan 24, 2019 at 04:51:37PM +0100, Andrew Lunn wrote:
> > > On Thu, Jan 24, 2019 at 02:18:03PM +0100, Thomas Bogendoerfer wrote:
> > > > Set up link interrupt if connection is handled by phylink otherwise
> > > > link state change detection for in-band-status doesn't work.
> > >
> > > Hi Thomas
> > >
> > > Please ensure the maintainers of the driver are at least on Cc:
> >
> > ... and other interested parties!
>
> Hi Russell
>
> get_maintainer.pl does not list you, so it can be hard to know who
> those other interested parties are. I have local knowledge, so added
> you :-)
Well, I don't maintain the driver, so get_maintainer.pl wouldn't list
me in any case.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net] net: mvpp2: fix condition for setting up link interrupt
From: Thomas Bogendoerfer @ 2019-01-24 16:17 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, antoine.tenart, maxime.chevallier, David S. Miller,
netdev, linux-kernel
In-Reply-To: <20190124160741.jady3r2e4dme7c4m@e5254000004ec.dyn.armlinux.org.uk>
On Thu, 24 Jan 2019 16:07:41 +0000
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> On Thu, Jan 24, 2019 at 04:51:37PM +0100, Andrew Lunn wrote:
> > On Thu, Jan 24, 2019 at 02:18:03PM +0100, Thomas Bogendoerfer wrote:
> > > Set up link interrupt if connection is handled by phylink otherwise
> > > link state change detection for in-band-status doesn't work.
> >
> > Hi Thomas
> >
> > Please ensure the maintainers of the driver are at least on Cc:
>
> ... and other interested parties!
sorry about missing maintainers, but how could I find "other interested
parties" ? /me thought that's handled by sending to mailinglists, which I did...
Thomas.
--
SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH net] net: mvpp2: fix condition for setting up link interrupt
From: Andrew Lunn @ 2019-01-24 16:15 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Thomas Bogendoerfer, antoine.tenart, maxime.chevallier,
David S. Miller, netdev, linux-kernel
In-Reply-To: <20190124160741.jady3r2e4dme7c4m@e5254000004ec.dyn.armlinux.org.uk>
On Thu, Jan 24, 2019 at 04:07:41PM +0000, Russell King - ARM Linux admin wrote:
> On Thu, Jan 24, 2019 at 04:51:37PM +0100, Andrew Lunn wrote:
> > On Thu, Jan 24, 2019 at 02:18:03PM +0100, Thomas Bogendoerfer wrote:
> > > Set up link interrupt if connection is handled by phylink otherwise
> > > link state change detection for in-band-status doesn't work.
> >
> > Hi Thomas
> >
> > Please ensure the maintainers of the driver are at least on Cc:
>
> ... and other interested parties!
Hi Russell
get_maintainer.pl does not list you, so it can be hard to know who
those other interested parties are. I have local knowledge, so added
you :-)
Andrew
^ permalink raw reply
* Re: [PATCH net] net: mvpp2: fix condition for setting up link interrupt
From: Thomas Bogendoerfer @ 2019-01-24 16:15 UTC (permalink / raw)
To: Andrew Lunn
Cc: antoine.tenart, maxime.chevallier, David S. Miller, netdev,
linux-kernel, Russell King
In-Reply-To: <20190124155137.GD482@lunn.ch>
On Thu, 24 Jan 2019 16:51:37 +0100
Andrew Lunn <andrew@lunn.ch> wrote:
> On Thu, Jan 24, 2019 at 02:18:03PM +0100, Thomas Bogendoerfer wrote:
> > Set up link interrupt if connection is handled by phylink otherwise
> > link state change detection for in-band-status doesn't work.
>
> Hi Thomas
>
> Please ensure the maintainers of the driver are at least on Cc:
I've hoped my script will get them, but it used --nogit-fallback, which prevented
finding maintainers... Sorry about that
Thomas.
--
SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH net-next v1 1/2] net: dsa: mv88e6xxx: Default CMODE to 1000BaseX only on 6390X
From: Andrew Lunn @ 2019-01-24 16:11 UTC (permalink / raw)
To: Marek Behún; +Cc: netdev, Florian Fainelli, David Miller
In-Reply-To: <20190124154309.24987-1-marek.behun@nic.cz>
On Thu, Jan 24, 2019 at 04:43:08PM +0100, Marek Behún wrote:
> Commit 787799a9d555 sets the SERDES interfaces of 6390 and 6390X to
> 1000BaseX, but this is only needed on 6390X, since there are SERDES
> interfaces which can be used on lower ports on 6390.
>
> This commit fixes this by returning to previous behaviour on 6390.
> (Previous behaviour means that CMODE is not set at all if requested mode
> is NA).
>
> This is needed on Turris MOX, where the 88e6190 is connected to CPU in
> 2500BaseX mode.
>
> Fixes: 787799a9d555 ("net: dsa: mv88e6xxx: Default ports 9/10 6390X CMODE to 1000BaseX")
> Signed-off-by: Marek Behún <marek.behun@nic.cz>
> ---
> drivers/net/dsa/mv88e6xxx/port.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
> index ebd26b6a93e6..ee7029f4ee22 100644
> --- a/drivers/net/dsa/mv88e6xxx/port.c
> +++ b/drivers/net/dsa/mv88e6xxx/port.c
> @@ -444,6 +444,8 @@ int mv88e6390_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
> phy_interface_t mode)
> {
> switch (mode) {
> + case PHY_INTERFACE_MODE_NA:
> + return 0;
Hi Marek
Although the previous behaviour might of allowed the cmode to be NA,
i'm not sure that is a good idea. How do you know the port actually is
using 2500BaseX, and not SGMII for example?
You really should set the interface mode in the device tree file, so
you know it does have the value you want.
Andrew
^ permalink raw reply
* Re: [PATCH net] net: mvpp2: fix condition for setting up link interrupt
From: Russell King - ARM Linux admin @ 2019-01-24 16:07 UTC (permalink / raw)
To: Andrew Lunn
Cc: Thomas Bogendoerfer, antoine.tenart, maxime.chevallier,
David S. Miller, netdev, linux-kernel
In-Reply-To: <20190124155137.GD482@lunn.ch>
On Thu, Jan 24, 2019 at 04:51:37PM +0100, Andrew Lunn wrote:
> On Thu, Jan 24, 2019 at 02:18:03PM +0100, Thomas Bogendoerfer wrote:
> > Set up link interrupt if connection is handled by phylink otherwise
> > link state change detection for in-band-status doesn't work.
>
> Hi Thomas
>
> Please ensure the maintainers of the driver are at least on Cc:
... and other interested parties!
> Thanks
> Andrew
>
> >
> > Fixes: 4bb043262878 ("net: mvpp2: phylink support")
> > Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> > ---
> > drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > index 16066c2d5b3a..0fbfe1945a69 100644
> > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > @@ -3405,7 +3405,7 @@ static int mvpp2_open(struct net_device *dev)
> > valid = true;
> > }
> >
> > - if (priv->hw_version == MVPP22 && port->link_irq && !port->phylink) {
> > + if (priv->hw_version == MVPP22 && port->link_irq && port->phylink) {
> > err = request_irq(port->link_irq, mvpp2_link_status_isr, 0,
> > dev->name, port);
> > if (err) {
This still looks fishy to me. mvpp2_link_status_isr() has handling in
it that is safe to be called for non-phylink cases, so presumably the
right fix is to drop the "&& !port->phylink" completely?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next v1 2/2] net: dsa: mv88e6xxx: Fix phylink_validate for Topaz family
From: Andrew Lunn @ 2019-01-24 16:01 UTC (permalink / raw)
To: Marek Behún; +Cc: netdev, Florian Fainelli, David Miller
In-Reply-To: <20190124154309.24987-2-marek.behun@nic.cz>
On Thu, Jan 24, 2019 at 04:43:09PM +0100, Marek Behún wrote:
> The Topaz family should have different phylink_validate method from the
> Peridot, since on Topaz the port supporting 2500BaseX mode is port 5,
> not 9 and 10.
>
> Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2] net: l2tp: fix reading optional fields of L2TPv3
From: Guillaume Nault @ 2019-01-24 16:01 UTC (permalink / raw)
To: Jacob Wen; +Cc: netdev, eric.dumazet, g.nault
In-Reply-To: <20190124074917.31173-1-jian.w.wen@oracle.com>
On Thu, Jan 24, 2019 at 03:49:17PM +0800, Jacob Wen wrote:
> Use pskb_may_pull() to make sure the optional fields are in skb linear
> parts, so we can safely read them later.
>
> It's easy to reproduce the issue with a net driver that supports paged
> skb data. Just create a L2TPv3 over IP tunnel and then generates some
> network traffic.
> Once reproduced, rx err in /sys/kernel/debug/l2tp/tunnels will increase.
>
> Signed-off-by: Jacob Wen <jian.w.wen@oracle.com>
> ---
> Changes in v2:
> 1. Only fix L2TPv3 to make code simple.
> To fix both L2TPv3 and L2TPv2, we'd better refactor l2tp_recv_common.
> It's complicated to do so.
>
Yes, the L2TP data path definitely needs some care. But for a one-off
patch like this, it'd probably make more sense to respect the current
code structure instead of adding yet more special cases.
I mean, l2tp_recv_common() assumes that it can safely access the L2TP
header: pskb_may_pull() is done in l2tp_udp_recv_core() (which probably
should pull more bytes in case the length field is present BTW).
It's up to l2tp_ip (and l2tp_ip6) to respect this requirement, so that's
where pskb_may_pull() should be done. Yes it'd be better to linearise
data close to the place we access them, but that'd be long term
refactoring. If we don't have the resources to do that, let's just, at
least keep some consistency.
^ permalink raw reply
* Want to start it?
From: Denna @ 2019-01-24 10:20 UTC (permalink / raw)
To: netdev
Please let me know the status of your photos, waiting to retouching them.
Do your photos need white background? sharpen? retouching? We can do it for
you.
Send us the test photos today and we can start to work on them.
Thanks,
Denna
^ 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