On Mon, Dec 3, 2018 at 11:30 PM Cong Wang wrote:
>
> On Mon, Dec 3, 2018 at 11:08 PM Eric Dumazet wrote:
> >
> > The hardware has probably validated the L3 & L4 checksum just fine.
> >
> > Note that if ip_summed is CHECKSUM_UNNECESSARY, the padding bytes (if any)
> > have no impact on the csum
On Mon, Dec 03, 2018 at 01:32:45PM -0500, Doug Ledford wrote:
> On Mon, 2018-11-26 at 08:28 +0200, Leon Romanovsky wrote:
> > From: Yishai Hadas
> >
> > Expose device capabilities for DEVX user context, it includes which caps
> > the device is supported and a matching bit to set as part of user
>
From: Willem de Bruijn
Date: Fri, 30 Nov 2018 15:32:38 -0500
> Enable MSG_ZEROCOPY for udp sockets
Series applied, thanks for keeping up with this.
From: Toke Høiland-Jørgensen
Date: Mon, 03 Dec 2018 22:00:32 +0200
> I wonder if it would be possible to support both the "give me user
> normal stats" case and the "let me do whatever I want" case by a
> combination of userspace tooling and maybe a helper or two?
>
> I.e., create a
On 12/3/18 5:00 PM, David Miller wrote:
> From: Toke Høiland-Jørgensen
> Date: Mon, 03 Dec 2018 22:00:32 +0200
>
>> I wonder if it would be possible to support both the "give me user
>> normal stats" case and the "let me do whatever I want" case by a
>> combination of userspace tooling and maybe
From: Tariq Toukan
Date: Sun, 2 Dec 2018 14:34:35 +0200
> This patchset includes small fixes for the mlx4_en driver.
>
> First patch by Eran fixes the value used to init the netdevice's
> min_mtu field.
> Please queue it to -stable >= v4.10.
>
> Second patch by Saeed adds missing Kconfig
On 12/3/2018 3:52 PM, David Ahern wrote:
> On 11/27/18 3:40 PM, Amritha Nambiar wrote:
>> Added support for filtering based on port ranges.
>> UAPI changes have been accepted into net-next.
>>
>> Example:
>> 1. Match on a port range:
>> -
>> $ tc filter add dev enp4s0
From: Xin Long
Date: Sat, 1 Dec 2018 01:36:59 +0800
> In sctp_hash_transport/sctp_epaddr_lookup_transport, it dereferences
> a transport's asoc under rcu_read_lock while asoc is freed not after
> a grace period, which leads to a use-after-free panic.
>
> This patch fixes it by calling
On Mon, 3 Dec 2018 22:42:04 +, Paul Burton wrote:
> Jiong Wang wrote:
> > For micro-mips, srlv inside POOL32A encoding space should use 0x50
> > sub-opcode, NOT 0x90.
> >
> > Some early version ISA doc describes the encoding as 0x90 for both srlv and
> > srav, this looks to me was a typo. I
From: Jerin Jacob
Date: Sun, 2 Dec 2018 18:17:35 +0530
> This patchset is a continuation to earlier submitted four patch
> series to add a new driver for Marvell's OcteonTX2 SOC's
> Resource virtualization unit (RVU) admin function driver.
>
> 1. octeontx2-af: Add RVU Admin Function driver
>
On Tue, 4 Dec 2018 00:06:24 +, Paul Burton wrote:
> If you have related patches the best thing to do would be to submit them
> together as a series. Then after the maintainers involved can see the
> patches we can figure out the best way to apply them.
Right, in hindsight that could've worked
On Mon, 12 Nov 2018 12:30:47 +, Russell King wrote:
> Add the Marvell Armada 38x common phy bindings.
>
> Signed-off-by: Russell King
> ---
> .../bindings/phy/phy-armada38x-comphy.txt | 40
> ++
> 1 file changed, 40 insertions(+)
> create mode 100644
>
Hi Jakub,
On Mon, Dec 03, 2018 at 03:55:45PM -0800, Jakub Kicinski wrote:
> On Mon, 3 Dec 2018 22:42:04 +, Paul Burton wrote:
> > Jiong Wang wrote:
> > > For micro-mips, srlv inside POOL32A encoding space should use 0x50
> > > sub-opcode, NOT 0x90.
> > >
> > > Some early version ISA doc
When testing high-bandwidth TCP streams with large windows,
high latency, and low jitter, netem consumes a lot of CPU cycles
doing rbtree rebalancing.
This patch uses a linear list/queue in addition to the rbtree:
if an incoming packet is past the tail of the linear queue, it is
added there,
On Mon, Dec 3, 2018 at 10:34 PM Eric Dumazet wrote:
>
> On Mon, Dec 3, 2018 at 10:14 PM Cong Wang wrote:
> >
> > When an ethernet frame is padded to meet the minimum ethernet frame
> > size, the padding octets are not covered by the hardware checksum.
> > Fortunately the padding octets are
On 12/3/18 4:58 PM, Nambiar, Amritha wrote:
> A previous version v3 of this patch was already applied to iproute2-next.
> https://patchwork.ozlabs.org/patch/998644/
>
> I think that needs to be reverted for this v6 to apply clean.
ugh. That's embarrassing. Looks like I inadvertently pushed the
From: Matteo Croce
Date: Sat, 1 Dec 2018 00:26:27 +0100
> A MAC address must be unique among all the macvlan devices with the same
> lower device. The only exception is the passthru [sic] mode,
> which shares the lower device address.
>
> When duplicate addresses are detected, EBUSY is
pathological bpf programs may try to force verifier to explode in
the number of branch states:
20: (d5) if r1 s<= 0x2428 goto pc+0
21: (b5) if r0 <= 0xe1fa20 goto pc+2
22: (d5) if r1 s<= 0x7e goto pc+0
23: (b5) if r0 <= 0xe880e000 goto pc+0
24: (c5) if r0 s< 0x2100ecf4 goto pc+0
Three patches to improve verifier ability to handle pathological bpf programs
with a lot of branches:
- make sure prog_load syscall can be aborted
- improve branch taken analysis
- introduce per-insn complexity limit for unprivileged programs
Alexei Starovoitov (3):
bpf: check pending signals
malicious bpf program may try to force the verifier to remember
a lot of distinct verifier states.
Put a limit to number of per-insn 'struct bpf_verifier_state'.
Note that hitting the limit doesn't reject the program.
It potentially makes the verifier do more steps to analyze the program.
It means
Malicious user space may try to force the verifier to use as much cpu
time and memory as possible. Hence check for pending signals
while verifying the program.
Note that suspend of sys_bpf(PROG_LOAD) syscall will lead to EAGAIN,
since the kernel has to release the resources used for program
On Wed, Nov 28, 2018 at 08:53:32PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Hi Doug and Jason,
>
> This series is intended to be applied on mlx5-next after Saeed's
> infrastructure changes series are accepted:
> https://patchwork.kernel.org/project/linux-rdma/list/?series=47809
>
From:
Date: Mon, 3 Dec 2018 08:26:52 +
> Can you please delay a bit the acceptance of this series, I would like
> that we assess these findings with tests on our hardware before applying
> them.
Sure.
On Mon, Nov 12, 2018 at 12:31:02PM +, Russell King wrote:
> Signed-off-by: Russell King
Needs a better subject and a commit msg.
> ---
> Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
>
From: Thomas Falcon
Date: Fri, 30 Nov 2018 10:59:08 -0600
> Commit a5681e20b541 ("net/ibmnvic: Fix deadlock problem
> in reset") made the change to hold the RTNL lock during
> driver reset but still calls netdev_notify_peers, which
> results in a deadlock. Instead, use call_netdevice_notifiers,
From: Jose Abreu
Date: Sun, 2 Dec 2018 16:33:14 +0100
> Logic of phy_device_create() requests PHY modules according to PHY ID
> but for C45 PHYs we use different field for the IDs.
>
> Let's also request the modules for these IDs.
>
> Changes from v1:
> - Only request C22 modules if C45 are
Hi Bjorn,
On 3/12/18 9:34 pm, Bjørn Mork wrote:
[ fixed Johns address - the openwrt.org email was apparently never restored? ]
Greg Ungerer writes:
The following change helped alot, but I still get some problems under
sustained load and some types of port setups. Still trying to figure
out
From: Ido Schimmel
Date: Fri, 30 Nov 2018 19:00:24 +0200
> Yes, agree. Patch is good. I'll tag your v2.
This means, I assume, that a new version of this fix is coming.
Eric, is this correct?
On 11/27/18 3:40 PM, Amritha Nambiar wrote:
> Added support for filtering based on port ranges.
> UAPI changes have been accepted into net-next.
>
> Example:
> 1. Match on a port range:
> -
> $ tc filter add dev enp4s0 protocol ip parent :\
> prio 1 flower ip_proto
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
---
tools/testing/selftests/bpf/Makefile | 3 +
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
We want to make sure that the following condition holds:
0 <= nhoff <= thoff <= skb->len
BPF program can set out-of-bounds nhoff and thoff, which is dangerous, see
recent commit d0c081b49137 ("flow_dissector: properly cap thoff field")'.
Signed-off-by: Stanislav Fomichev
---
We are returning thoff from the flow dissector, not the nhoff. Pass
thoff along with nhoff to the bpf program (initially thoff == nhoff)
and expect flow dissector amend/return thoff, not nhoff.
This avoids confusion, when by the time bpf flow dissector exits,
nhoff == thoff, which doesn't make
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
---
include/linux/bpf.h | 3 ++
net/bpf/test_run.c | 71 -
This way, we can reuse it for flow dissector in BPF_PROG_TEST_RUN.
No functional changes.
Signed-off-by: Stanislav Fomichev
---
include/linux/skbuff.h| 5 +++
net/core/flow_dissector.c | 85 +++
2 files changed, 56 insertions(+), 34 deletions(-)
diff
From: David Ahern
Date: Mon, 3 Dec 2018 17:15:03 -0700
> So, instead of a program tag which the program writer controls, how
> about some config knob that an admin controls that says at attach time
> use standard stats?
How about, instead of replacing it is in addition to, and admin can
From: Tariq Toukan
Date: Sun, 2 Dec 2018 17:40:24 +0200
> This patchset by Erez contains cleanups to the mlx4_core driver.
>
> Patch 1 replaces -EINVAL with -EOPNOTSUPP for unsupported operations.
> Patch 2 fixes some coding style issues.
>
> Series generated against net-next commit:
>
The error return code PTR_ERR(gpr_np) is always 0 since gpr_np is
equal to NULL in this error handling case. Fix it by return -ENOENT.
Fixes: de3578c198c6 ("can: flexcan: add self wakeup support")
Signed-off-by: Wei Yongjun
---
drivers/net/can/flexcan.c | 2 +-
1 file changed, 1 insertion(+), 1
On Tue, 04 Dec 2018 09:03:52 +0200, Toke Høiland-Jørgensen wrote:
> David Miller writes:
>
> > From: David Ahern
> > Date: Mon, 3 Dec 2018 17:15:03 -0700
> >
> >> So, instead of a program tag which the program writer controls, how
> >> about some config knob that an admin controls that says
On 12/03, Stanislav Fomichev wrote:
> On 12/03, Song Liu wrote:
> > On Mon, Dec 3, 2018 at 11:00 AM 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.
> >
When an ethernet frame is padded to meet the minimum ethernet frame
size, the padding octets are not covered by the hardware checksum.
Fortunately the padding octets are ususally zero's, which don't affect
checksum. However, we have a switch which pads non-zero octets, this
causes kernel hardware
Resent to netdev@ without htm formatting, sorry.
On Mon, Dec 3, 2018 at 11:08 PM Eric Dumazet wrote:
>
>
>
> On Mon, Dec 3, 2018 at 10:48 PM Cong Wang wrote:
>>
>> On Mon, Dec 3, 2018 at 10:34 PM Eric Dumazet wrote:
>> >
>> > On Mon, Dec 3, 2018 at 10:14 PM Cong Wang wrote:
>> > >
>> > > When
On Mon, Dec 3, 2018 at 11:08 PM Eric Dumazet wrote:
>
> The hardware has probably validated the L3 & L4 checksum just fine.
>
> Note that if ip_summed is CHECKSUM_UNNECESSARY, the padding bytes (if any)
> have no impact on the csum that has been verified by the NIC.
Why? Why does the hardware
On Mon, Dec 3, 2018 at 10:14 PM Cong Wang wrote:
>
> When an ethernet frame is padded to meet the minimum ethernet frame
> size, the padding octets are not covered by the hardware checksum.
> Fortunately the padding octets are ususally zero's, which don't affect
> checksum. However, we have a
David Miller writes:
> From: David Ahern
> Date: Mon, 3 Dec 2018 17:15:03 -0700
>
>> So, instead of a program tag which the program writer controls, how
>> about some config knob that an admin controls that says at attach time
>> use standard stats?
>
> How about, instead of replacing it is in
Hi,
Kernel version; 4.19.3
A multipath ipv6 route is setup;
# ip -6 ro
1000:: proto zebra metric 20
nexthop via 1000::1:c0a8:101 dev eth1 weight 1
nexthop via 1000::1:c0a8:104 dev eth1 weight 1
nexthop via 1000::1:c0a8:102 dev eth1 weight 1
nexthop via
Hi,
On 3.12.2018 6:52, Harini Katakam wrote:
> Hi Anssi,
> On Fri, Nov 30, 2018 at 11:53 PM Anssi Hannula
> wrote:
>> Bit RX_USED set to 0 in the address field allows the controller to write
>> data to the receive buffer descriptor.
>>
>> The driver does not ensure the ctrl field is ready
I'm afraid Roman's patch doesn't fix the bug.
On Fri, Nov 30, 2018 at 02:58:03PM -0800, Alexei Starovoitov wrote:
> On Thu, Nov 29, 2018 at 01:27:03PM +0300, Dan Carpenter wrote:
> > Smatch complains that if bpf_test_run() fails with -ENOMEM at the
> > begining then the "duration" is
Add a new function, which encourages safe usage of the test interface.
bpf_prog_test_run continues to work as before, but should be considered
unsafe.
Signed-off-by: Lorenz Bauer
---
tools/lib/bpf/bpf.c | 23 +++
tools/lib/bpf/bpf.h | 19 +++
On Fri, 2018-11-30 at 15:32 -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn
>
> Extend zerocopy to udp sockets. Allow setting sockopt SO_ZEROCOPY and
> interpret flag MSG_ZEROCOPY.
>
> This patch was previously part of the zerocopy RFC patchsets. Zerocopy
> is not effective at small
When NULL pointer accidentally passed to write_kprobe_events,
due to strlen(NULL), segmentation fault happens.
Changed code returns -1 to deal with this situation.
Bug issued with Smatch, static analysis.
Signed-off-by: Daniel T. Lee
---
samples/bpf/bpf_load.c | 4 +++-
1 file changed, 3
The timecounter needs to be updated at least once in half of the
cyclecounter interval to prevent timecounter_cyc2time() interpreting a
new timestamp as an old value and causing a backward jump.
This would be an issue if the timecounter multiplier was so small that
the update interval would not
Read the system time right before and immediately after reading the low
register of the internal timer. This adds support for the
PTP_SYS_OFFSET_EXTENDED ioctl.
Cc: Richard Cochran
Cc: Saeed Mahameed
Signed-off-by: Miroslav Lichvar
---
.../ethernet/mellanox/mlx5/core/lib/clock.c | 20
This is a pair of patches for the mlx5 driver related to the PTP clock.
The first patch fixes a potential issue causing backward jumps due to a
late update of the PHC timecounter.
The second patch adds support for the PTP_SYS_OFFSET_EXTENDED ioctl.
Miroslav Lichvar (2):
mlx5: update
On Mon, Dec 03, 2018 at 11:18:14AM +0100, Emeric Dupont wrote:
> When performing make install in iproute2 (current git master),
> if $(HAVE_MNL) is not selected, some Makefiles try to call
> install with an empty target, which causes a non-critical make error.
>
> Signed-off-by: Emeric
[ fixed Johns address - the openwrt.org email was apparently never restored? ]
Greg Ungerer writes:
> The following change helped alot, but I still get some problems under
> sustained load and some types of port setups. Still trying to figure
> out what exactly is going on.
>
> ---
On 1.12.2018 0:16, Heiner Kallweit wrote:
> On 30.11.2018 19:45, Anssi Hannula wrote:
>> When a PHY_HALTED phydev is resumed by phy_start(), it is set to
>> PHY_RESUMING to wait for the link to come up.
>>
>> However, if the phydev was put to PHY_HALTED (by e.g. phy_stop()) before
>>
When performing make install in iproute2 (current git master),
if $(HAVE_MNL) is not selected, some Makefiles try to call
install with an empty target, which causes a non-critical make error.
Signed-off-by: Emeric Dupont
---
devlink/Makefile | 4 +++-
rdma/Makefile| 4 +++-
Pull changes from "bpf: respect size hint to BPF_PROG_TEST_RUN if present".
Signed-off-by: Lorenz Bauer
---
tools/include/uapi/linux/bpf.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index
Use data_size_out as a size hint when copying test output to user space.
ENOSPC is returned if the output buffer is too small.
Callers which so far did not set data_size_out are not affected.
Signed-off-by: Lorenz Bauer
---
include/uapi/linux/bpf.h | 7 +--
net/bpf/test_run.c | 15
Right now, there is no safe way to use BPF_PROG_TEST_RUN with data_out.
This is because bpf_test_finish copies the output buffer to user space
without checking its size. This can lead to the kernel overwriting
data in user space after the buffer if xdp_adjust_head and friends are
in play.
Thanks
Make sure that bpf_prog_test_run_xattr returns the correct length
and that the kernel respects the output size hint. Also check
that errno indicates ENOSPC if there is a short output buffer given.
Signed-off-by: Lorenz Bauer
---
tools/testing/selftests/bpf/test_progs.c | 55
Hi Anssi,
On Mon, Dec 3, 2018 at 4:02 PM Anssi Hannula wrote:
>
> Hi,
>
> On 3.12.2018 6:52, Harini Katakam wrote:
> > Hi Anssi,
> > On Fri, Nov 30, 2018 at 11:53 PM Anssi Hannula
> > wrote:
> >> Bit RX_USED set to 0 in the address field allows the controller to write
> >> data to the receive
The missing indentation on the "Return" sections for bpf_map_pop_elem()
and bpf_map_peek_elem() helpers break RST and man pages generation. This
patch fixes them, and moves the description of those two helpers towards
the end of the list (even though they are somehow related to the three
first
On Fri, 2018-11-30 at 15:32 -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn
>
> With MSG_ZEROCOPY, each skb holds a reference to a struct ubuf_info.
> Release of its last reference triggers a completion notification.
>
> The TCP stack in tcp_sendmsg_locked holds an extra ref independent
When performing make install in iproute2 (current git master),
if $(HAVE_MNL) is not selected, some Makefiles try to call
install with an empty target, which causes a non-critical make error.
Signed-off-by: Emeric Dupont
---
devlink/Makefile | 4 +++-
rdma/Makefile| 4 +++-
Currently, duplicated rules are rejected only for skip_hw or "none",
hence allowing users to push duplicated into HW for no reason.
Use the flower tables to protect for that.
Signed-off-by: Or Gerlitz
Signed-off-by: Paul Blakey
Reported-by: Chris Mi
---
net/sched/cls_flower.c | 18
This avoids another indirect call for UDP GRO. Again, the test
for the IPv6 variant is performed first.
Signed-off-by: Paolo Abeni
---
net/ipv4/udp.c | 2 ++
net/ipv4/udp_offload.c | 6 --
net/ipv6/udp.c | 2 ++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git
This avoids an indirect call in the receive path for TCP and UDP
packets. TCP takes precedence on UDP, so that we have a single
additional conditional in the common case.
Signed-off-by: Paolo Abeni
---
include/net/inet_common.h | 7 +++
net/ipv4/af_inet.c| 11 +--
This avoids an indirect calls for L3 GRO receive path, both
for ipv4 and ipv6, if the latter is not compiled as a module.
Note that when IPv6 is compiled as builtin, it will be checked first,
so we have a single additional compare for the more common path.
Signed-off-by: Paolo Abeni
---
This header define a bunch of helpers that allow avoiding the
retpoline overhead when calling builtin functions via function pointers.
It boils down to explicitly comparing the function pointers to
known builtin functions and eventually invoke directly the latter.
The macros defined here
The spectre v2 counter-measures, aka retpolines, are a source of measurable
overhead[1]. We can partially address that when the function pointer refers to
a builtin symbol resorting to a list of tests vs well-known builtin function and
direct calls.
Experimental results[2] shows that replacing a
On Mon, Dec 03, 2018 at 08:04:57AM +0100, Heiner Kallweit wrote:
> Currently __set_phy_supported allows to add modes w/o checking whether
> the PHY supports them. This is wrong, it should never add modes but
> only remove modes we don't want to support.
>
> Signed-off-by: Heiner Kallweit
> >I don't think any of these properties are necessary, if you can either
> >use a compatible string, and/or infer the actual model at runtime in the
> >driver's probe function, then you can assess based on that chip model as
>
> There is an ID register in the 7530 - though I don't know if the
On Mon, Dec 03, 2018 at 06:09:24PM +0900, Prashant Bhole wrote:
> In tun.c skb->len was accessed while doing stats accounting after a
> call to netif_receive_skb. We can not access skb after this call
> because buffers may be dropped.
>
> The fix for this bug would be to store skb->len in local
On Mon, Dec 03, 2018 at 08:19:33AM +0100, Heiner Kallweit wrote:
> Currently __set_phy_supported allows to add modes w/o checking whether
> the PHY supports them. This is wrong, it should never add modes but
> only remove modes we don't want to support.
>
> The commit marked as fixed didn't do
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yangtao Li
---
drivers/net/wireless/ath/wil6210/debugfs.c | 240 -
1 file changed, 42 insertions(+), 198 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c
Hi Daniel,
On 03/12/18 6:18 PM, Daniel Borkmann wrote:
>
> Thanks for the patch, just to clarify, it's targeted at bpf-next and
> not bpf, correct?
>
This patch is targeted at the bpf tree.
This depends on commit e2c95a61656d ("bpf, ppc64: generalize fetching
subprog into
Hi,
I ran into a panic while adding an interface to a bridge with a vxlan
interface already attached to it, as it seems related mtu=9000.
I get the following panic info :
[ 2482.419893] br100: port 2(vif1.1) entered blocking state
[ 2482.425427] br100: port 2(vif1.1) entered forwarding state
[
Creating a VXLAN device with is underlay in the non-default VRF makes
egress route lookup fail or incorrect since it will resolve in the
default VRF, and ingress fail because the socket listens in the default
VRF.
This patch binds the underlying UDP tunnel socket to the l3mdev of the
lower device
This script tests the support of a VXLAN underlay in a non-default VRF.
It does so by simulating two hypervisors and two VMs, an extended L2
between the VMs with the hypervisors as VTEPs with the underlay in a
VRF, and finally by pinging the two VMs.
It also tests that moving the underlay from a
Existing functions to retreive the l3mdev of a device did not walk the
master chain to find the upper master. This patch adds a function to
find the l3mdev, even indirect through e.g. a bridge:
+--+
| |
| vrf-blue |
| |
++-+
|
|
++-+
|
v6 -> v7:
- proper locking for device in udp_tunnel following Sabrina Dubroca's advice
v5 -> v6:
- remove automatic rebinding patch following Roopa Prabhu's advice
v4 -> v5:
- move test script to its own patch (6/6)
- add schematic for test script
- apply David Ahern comments to the test script
UDP tunnel sockets are always opened unbound to a specific device. This
patch allow the socket to be bound on a custom device, which
incidentally makes UDP tunnels VRF-aware if binding to an l3mdev.
Signed-off-by: Alexis Bauvin
Reviewed-by: Amine Kherbouche
Tested-by: Amine Kherbouche
---
Quoting Bjørn Mork :
Greg Ungerer writes:
The following change helped alot, but I still get some problems under
sustained load and some types of port setups. Still trying to figure
out what exactly is going on.
--- a/linux/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++
Our case is a bit different - it is more like using the SRH header in
IPv6 to route packets via a non-default intermediate hop. But I see
your point - I'll expand the patchset to cover IPv6 and the ingress
path.
On Mon, Dec 3, 2018 at 8:04 AM David Ahern wrote:
>
> On 11/30/18 5:14 PM, Peter
Hi,friend,
This is Daniel Murray and i am from Sinara Group Co.Ltd in Russia.
We are glad to know about your company from the web and we are interested in
your products.
Could you kindly send us your Latest catalog and price list for our trial order.
Best Regards,
Daniel Murray
Purchasing
On 12/1/18 4:22 AM, Jesper Dangaard Brouer wrote:
>>
>> So we should count all XDP RX packets as successful rx packets i.e
>> netdev->stats.rx_packets++; regardless of the XDP program decision ?
>
> Yes.
>
>> this implies that XDP_TX packets will be counted twice once in
>>
On 12/1/18 4:14 AM, Jesper Dangaard Brouer wrote:
>>> XDP dropping a packet is completely different.
>>>
>>> stats are important. packets disappearing with no counters -- standard
>>> counters visible by standard tools -- is a user nightmare. If the
>>> agreement is for XDP drops to be in driver
On 12/03/2018 07:20 AM, Nicolas Belouin wrote:
> Hi,
> I ran into a panic while adding an interface to a bridge with a vxlan
> interface already attached to it, as it seems related mtu=9000.
>
> I get the following panic info :
>
> [ 2482.419893] br100: port 2(vif1.1) entered blocking state
>
On 11/30/18 8:00 AM, Paweł Staszewski wrote:
>
> Traces attached below:
>
>
>
> [310658.536190] rcu: INFO: rcu_sched self-detected stall on CPU
> [310658.536195] rcu: 15-: (322 ticks this GP)
> idle=fca/1/0x4002 softirq=50617185/50617185 fqs=64
> [310658.536195] rcu:
On Mon, Dec 03, 2018 at 05:02:40PM +, Steve Douthit wrote:
> On 12/3/18 11:54 AM, Andrew Lunn wrote:
> >> +static s32 ixgbe_x550em_a_mii_bus_read(struct mii_bus *bus, int addr,
> >> + int regnum)
> >> +{
> >> + struct ixgbe_adapter *adapter = (struct
More checksum changes fallout?
Begin forwarded message:
Date: Mon, 03 Dec 2018 04:23:36 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 201849] New: hw csum failure - reproducible error
https://bugzilla.kernel.org/show_bug.cgi?id=201849
On Mon, Dec 3, 2018 at 8:45 AM Christoph Paasch wrote:
>
> On 29/11/18 - 14:59:36, Eric Dumazet wrote:
> > On Thu, Nov 29, 2018 at 2:47 PM Christoph Paasch wrote:
> >
> > > Indeed, the UDP-stack is not fully 4-tuple ready.
> > >
> > >
> > > What are your thoughts on getting it there?
> >
> >
> +static s32 ixgbe_x550em_a_mii_bus_read(struct mii_bus *bus, int addr,
> +int regnum)
> +{
> + struct ixgbe_adapter *adapter = (struct ixgbe_adapter *)bus->priv;
> + struct ixgbe_hw *hw = >hw;
> + u32 gssr = hw->phy.phy_semaphore_mask |
On 12/3/18 2:32 AM, Lars Ekman G wrote:
>
> Hi,
>
> Kernel version; 4.19.3
>
> A multipath ipv6 route is setup;
>
> # ip -6 ro
> 1000:: proto zebra metric 20
> nexthop via 1000::1:c0a8:101 dev eth1 weight 1
> nexthop via 1000::1:c0a8:104 dev eth1 weight 1
> nexthop
Most dsa devices expect a 'struct mii_bus' pointer to talk to switches
via the MII interface.
Signed-off-by: Stephen Douthit
---
drivers/net/ethernet/intel/Kconfig| 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 5 +
Use the mii_bus callbacks to address the entire clause 22/45 address
space. Enables userspace to poke switch registers instead of a single
PHY address.
Signed-off-by: Stephen Douthit
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 18 ++
1 file changed, 18 insertions(+)
Address review comments from v1. I missed the intel-wired-lan list on
the first submission, so check out the netdev list archive for the first
rev of the patch.
I think it's still up in the air on how best to register a single bus
that's shared among up to four MACs. This code works for me, but
On 12/3/18 11:54 AM, Andrew Lunn wrote:
>> +static s32 ixgbe_x550em_a_mii_bus_read(struct mii_bus *bus, int addr,
>> + int regnum)
>> +{
>> +struct ixgbe_adapter *adapter = (struct ixgbe_adapter *)bus->priv;
>> +struct ixgbe_hw *hw = >hw;
>> +u32 gssr
1 - 100 of 174 matches
Mail list logo
