Hi Alexandre,
On Thu, May 23, 2019 at 05:05:51PM +0200, Alexandre Torgue wrote:
> Hi Maxime
>
> On 5/23/19 11:56 AM, Maxime Ripard wrote:
> > Switch the STMMAC / Synopsys DesignWare MAC controller binding to a YAML
> > schema to enable the DT validation.
> >
> > Signed-off-by: Maxime Ripard
> > -
On 05/23/2019 05:48 PM, John Fastabend wrote:
> Backlog work for psock (sk_psock_backlog) might sleep while waiting
> for memory to free up when sending packets. However, while sleeping
> the socket may be closed and removed from the map by the user space
> side.
>
> This breaks an assumption in s
On 05/22/2019 05:17 AM, Alexei Starovoitov wrote:
> Convert explored_states array into hash table and use simple hash to
> reduce verifier peak memory consumption for programs with bpf2bpf calls.
> More details in patch 3.
>
> v1->v2: fixed Jakub's small nit in patch 1
>
> Alexei Starovoitov (3):
On Thu, May 23, 2019 at 05:58 PM CEST, John Fastabend wrote:
> [...]
>
>>
>> Thanks for taking a look at it. Setting MSG_DONTWAIT works great for
>> me. No more crashes in sk_stream_wait_memory. I've tested it on top of
>> current bpf-next (f49aa1de9836). Here's my:
>>
>> Tested-by: Jakub Sitnick
Hi Florian,
On Thu, May 23, 2019 at 11:16:55AM -0700, Florian Fainelli wrote:
> On 5/23/19 2:56 AM, Maxime Ripard wrote:
> > The networking PHYs have a number of available device tree properties that
> > can be used in their device tree node. Add a YAML schemas for those.
> >
> > Signed-off-by: Ma
Thu, May 23, 2019 at 05:19:46PM CEST, dsah...@gmail.com wrote:
>On 5/23/19 3:45 AM, Jiri Pirko wrote:
>> @@ -57,11 +58,13 @@ static int mlxfw_fsm_state_wait(struct mlxfw_dev
>> *mlxfw_dev, u32 fwhandle,
>> if (fsm_state_err != MLXFW_FSM_STATE_ERR_OK) {
>> pr_err("Firmware flash f
Thu, May 23, 2019 at 07:57:03PM CEST, jakub.kicin...@netronome.com wrote:
>On Thu, 23 May 2019 11:47:10 +0200, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> Listen to status notifications coming from kernel during flashing and
>> put them on stdout to inform user about the status.
>>
>> Signed-off
Thu, May 23, 2019 at 08:37:28PM CEST, sae...@mellanox.com wrote:
>On Thu, 2019-05-23 at 11:45 +0200, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> When user is flashing device using devlink, he currenly does not see
>> any
>> information about what is going on, percentages, etc.
>> Drivers, for exa
Thu, May 23, 2019 at 07:47:54PM CEST, jakub.kicin...@netronome.com wrote:
>On Thu, 23 May 2019 11:45:10 +0200, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> Signed-off-by: Jiri Pirko
>> ---
>> drivers/net/netdevsim/dev.c | 35 +++
>> 1 file changed, 35 insertions(+
Before the patch:
$ ip netns add foo
$ ip link add name veth1 address 2a:a5:5c:b9:52:89 type veth peer name veth2
address 2a:a5:5c:b9:53:90 netns foo
RTNETLINK answers: No such device
RTNETLINK answers: No such device
But the command was successful. This may break script. Let's remove those
error
Hi Rob,
On Thu, May 23, 2019 at 10:33:05AM -0500, Rob Herring wrote:
> On Thu, May 23, 2019 at 4:57 AM Maxime Ripard
> wrote:
> >
> > Switch the STMMAC / Synopsys DesignWare MAC controller binding to a YAML
> > schema to enable the DT validation.
>
> You picked an easy one. ;)
Yeah, that's what
2019-05-23 13:42 UTC-0700 ~ Andrii Nakryiko
> Document optional **c** option for btf dump subcommand.
>
> Cc: Quentin Monnet
> Signed-off-by: Andrii Nakryiko
> ---
> tools/bpf/bpftool/Documentation/bpftool-btf.rst | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/
Hi Andrii,
Some nits inline, nothing blocking though.
2019-05-23 13:42 UTC-0700 ~ Andrii Nakryiko
> Utilize new libbpf's btf_dump API to emit BTF as a C definitions.
>
> Signed-off-by: Andrii Nakryiko
> ---
> tools/bpf/bpftool/btf.c | 74 +++--
> 1 file cha
2019-05-23 13:42 UTC-0700 ~ Andrii Nakryiko
> Add bash completion for new C btf dump option.
>
> Cc: Quentin Monnet
> Signed-off-by: Andrii Nakryiko
> ---
> tools/bpf/bpftool/bash-completion/bpftool | 25 +++
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --gi
On Mon, May 20, 2019 at 10:35:07AM +0200, Nicolas Dichtel wrote:
> Le 06/05/2019 à 15:16, Pablo Neira Ayuso a écrit :
> > On Mon, May 06, 2019 at 10:49:52AM +0200, Nicolas Dichtel wrote:
> [snip]
> >> Is it possible to queue this for stable?
> >
> > Sure, as soon as this hits Linus' tree.
> >
> F
On Thu, 23 May 2019 13:15:44 -0700
Stephen Hemminger wrote:
> On Thu, 23 May 2019 19:19:40 +
> Saeed Mahameed wrote:
>
> > On Thu, 2019-05-23 at 10:54 -0700, Stephen Hemminger wrote:
> > > When a device is stacked like (team, bonding, failsafe or netvsc) the
> > > XDP generic program for
This series contains improvements to the AF_XDP kernel infrastructure
and AF_XDP support in mlx5e. The infrastructure improvements are
required for mlx5e, but also some of them benefit to all drivers, and
some can be useful for other drivers that want to implement AF_XDP.
The performance testing w
Add a function that checks whether the Fill Ring has the specified
amount of descriptors available. It will be useful for mlx5e that wants
to check in advance, whether it can allocate a bulk of RX descriptors,
to get the best performance.
Signed-off-by: Maxim Mikityanskiy
Reviewed-by: Tariq Touka
Make it possible for the application to determine whether the AF_XDP
socket is running in zero-copy mode. To achieve this, add a new
getsockopt option XDP_OPTIONS that returns flags. The only flag
supported for now is the zero-copy mode indicator.
Signed-off-by: Maxim Mikityanskiy
Acked-by: Saeed
Query XDP_OPTIONS in libbpf to determine if the zero-copy mode is active
or not.
Signed-off-by: Maxim Mikityanskiy
Acked-by: Saeed Mahameed
---
tools/lib/bpf/xsk.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index 38667b62f1fe..bedd
The PCI API for DMA is deprecated, and PCI_DMA_TODEVICE is just defined
to DMA_TO_DEVICE for backward compatibility. Just use DMA_TO_DEVICE.
Signed-off-by: Maxim Mikityanskiy
Reviewed-by: Tariq Toukan
Acked-by: Saeed Mahameed
---
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 2 +-
1 file
Put the XDP SQ that is used for XDP_TX into the channel. It used to be a
part of the RQ, but with introduction of AF_XDP there will be one more
RQ that could share the same XDP SQ. This patch is a preparation for
that change.
Separate XDP_TX statistics per RQ were implemented in one of the previou
Use the existing mlx5e_get_linear_rq_headroom function to calculate the
headroom for mlx5e_xdp_max_mtu. This function takes the XSK headroom
into consideration, which will be used in the following patches.
Signed-off-by: Maxim Mikityanskiy
Reviewed-by: Tariq Toukan
Acked-by: Saeed Mahameed
---
Currently, struct mlx5e_xdp_info has some issues that have to be cleaned
up before the upcoming AF_XDP support makes things too complicated and
messy. This structure is used both when sending the packet and on
completion. Moreover, the cleanup procedure on completion depends on the
origin of the pa
Additional conditions introduced:
- XSK implies XDP.
- Headroom includes the XSK headroom if it exists.
- No space is reserved for struct shared_skb_info in XSK mode.
- Fragment size smaller than the XSK chunk size is not allowed.
A new auxiliary function mlx5e_get_linear_rq_headroom with the sup
Some drivers want to access the data transmitted in order to implement
acceleration features of the NICs. It is also useful in AF_XDP TX flow.
Change the xsk_umem_consume_tx API to return the whole xdp_desc, that
contains the data pointer, length and DMA address, instead of only the
latter two. Ad
Create new functions mlx5e_{open,close}_queues to encapsulate opening
and closing RQs and SQs, and call the new functions from
mlx5e_{open,close}_channel. It simplifies the existing functions a bit
and prepares them for the upcoming AF_XDP changes.
Signed-off-by: Maxim Mikityanskiy
Reviewed-by: T
When an XDP program returns XDP_TX, and the RQ is XSK-enabled, it
requires careful handling, because convert_to_xdp_frame creates a new
page and copies the data there, while our driver expects the xdp_frame
to point to the same memory as the xdp_buff. Handle this case
separately: map the page, and
Prepare to creation of the XSK RQ, which will require posting UMRs, too.
The same ICO SQ will be used for both RQs and also to trigger interrupts
by posting NOPs. UMR WQEs can't be reused any more. Optimization
introduced in commit ab966d7e4ff98 ("net/mlx5e: RX, Recycle buffer of
UMR WQEs") is reve
The typical XDP memory scheme is one packet per page. Change the AF_XDP
frame size in libbpf to 4096, which is the page size on x86, to allow
libbpf to be used with the drivers with the packet-per-page scheme.
Add a command line option -f to xdpsock to allow to specify a custom
frame size.
Signed
structs mlx5e_{rq,sq,cq,channel}_param are going to be used in the
upcoming XSK RX and TX patches. Move them to a header file to make
them accessible from other C files.
Signed-off-by: Maxim Mikityanskiy
Reviewed-by: Tariq Toukan
Acked-by: Saeed Mahameed
---
.../ethernet/mellanox/mlx5/core/en/
Currently, the drivers that implement AF_XDP zero-copy support (e.g.,
i40e) switch the channel into a different mode when an XSK is opened. It
causes some issues that have to be taken into account. For example, RSS
needs to be reconfigured to skip the XSK-enabled channels, or the XDP
program should
2019-05-23 16:29 UTC+ ~ Yonghong Song
>
>
> On 5/23/19 9:19 AM, Yonghong Song wrote:
>>
>>
>> On 5/23/19 3:54 AM, Quentin Monnet wrote:
>>> libbpf was recently made aware of the log_level attribute for programs,
>>> used to specify the level of information expected to be dumped by the
>>> ve
2019-05-23 16:38 UTC+ ~ Yonghong Song
>
>
> On 5/23/19 3:54 AM, Quentin Monnet wrote:
>> The "-d" option is used to require all logs available for bpftool. So
>> far it meant telling libbpf to print even debug-level information. But
>> there is another source of info that can be made more ve
2019-05-23 13:57 UTC-0700 ~ Andrii Nakryiko
> On Thu, May 23, 2019 at 1:44 PM Jakub Kicinski
> wrote:
>>
>> On Thu, 23 May 2019 09:20:52 -0700, Andrii Nakryiko wrote:
>>> On Thu, May 23, 2019 at 3:54 AM Quentin Monnet wrote:
libbpf has three levels of priority for output messages: warn,
On Thu, 23 May 2019 22:51:34 +0900
Toshiaki Makita wrote:
> On 19/05/23 (木) 22:29:27, Jesper Dangaard Brouer wrote:
> > On Thu, 23 May 2019 20:35:50 +0900
> > Toshiaki Makita wrote:
> >
> >> On 2019/05/23 20:25, Toke Høiland-Jørgensen wrote:
> >>> Toshiaki Makita writes:
> >>>
>
On Fri, 24 May 2019 12:17:27 +0800
Jason Wang wrote:
> > Maybe this is acceptable, but it should be documented, as the current
> > assumption dictates: XDP program runs on the core where the XDP
> > frame/SKB was first seen.
>
>
> At lest for TUN, this is not true. XDP frames were built by vh
Hi Andreas,
2019-05-23, 09:46:15 +0200, Andreas Steinmetz wrote:
> MACsec causes oopses followed by a kernel panic when attached
> directly or indirectly to a bridge. It causes erroneous checksum
> messages when attached to vxlan.
It looks like you're fixing multiple separate bugs in a single pat
On 2019-05-24 11:35, Maxim Mikityanskiy wrote:
This series contains improvements to the AF_XDP kernel infrastructure
and AF_XDP support in mlx5e. The infrastructure improvements are
required for mlx5e, but also some of them benefit to all drivers, and
some can be useful for other drivers that wan
After reset SGMII Autoneg timer is set to 2us (bits 6 and 5 are 01).
That us not enough to finalize autonegatiation on some devices.
Increase this timer duration to maximum supported 16ms.
Signed-off-by: Max Uvarov
---
drivers/net/phy/dp83867.c | 13 +
1 file changed, 13 insertions(+
For support 10Mps sped in SGMII mode DP83867_10M_SGMII_RATE_ADAPT bit
of DP83867_10M_SGMII_CFG register has to be cleared by software.
That does not affect speeds 100 and 1000 so can be done on init.
Signed-off-by: Max Uvarov
---
drivers/net/phy/dp83867.c | 22 ++
1 file chan
Phy state machine calls _config_init just after
reset.
Signed-off-by: Max Uvarov
---
drivers/net/phy/dp83867.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 66b0a09ad094..2984fd5ae495 100644
--- a/drivers/net/phy/d
Patch "fix speed 10 in sgmii mode" I already sent before
and the was no mutch objections. Just resending it.
Patch "increase SGMII autoneg timer duration" fixes autoneg
between mac and the phy.
And the latest "do not call config_init twice" is the logical
code clean up.
BR,
Max.
Max Uvarov (3
> Subject: Re: [RFC PATCH net-next 2/9] net: phy: Guard against the presence of
> a
> netdev
>
> On Thu, May 23, 2019 at 01:20:38AM +, Ioana Ciornei wrote:
> > A prerequisite for PHYLIB to work in the absence of a struct
> > net_device is to not access pointers to it.
> >
> > Changes are ne
Hi Kevin
I couldn't get 'git am' to accept your email. Not sure if it's because
it's base64 encoded, or because it doesn't apply cleanly to current
net-next.
However, I could get it to apply by manually copying over the diff to a
.patch file, so here are some comments:
> ctinfo is a new tc filte
PHY_INTERFACE_MODE_RGMII_RXID is less then TXID
so code to set tx delay is never called.
Signed-off-by: Max Uvarov
---
drivers/net/phy/dp83867.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 2984fd5ae495..5fed83
libbpf has three levels of priority for output messages: warn, info,
debug. By default, debug output is not printed to the console.
Add a new "--debug" (short name: "-d") option to bpftool to print libbpf
logs for all three levels.
Internally, we simply use the function provided by libbpf to repl
libbpf was recently made aware of the log_level attribute for programs,
used to specify the level of information expected to be dumped by the
verifier. Function bpf_prog_load_xattr() got support for this log_level
parameter.
But some applications using libbpf rely on another function to load
progr
Hi,
This series adds an option to bpftool to make it print additional
information via libbpf and the kernel verifier when attempting to load
programs.
A new API function is added to libbpf in order to pass the log_level from
bpftool with the bpf_object__* part of the API.
Options for a finer cont
The "-d" option is used to require all logs available for bpftool. So
far it meant telling libbpf to print even debug-level information. But
there is another source of info that can be made more verbose: when we
attemt to load programs with bpftool, we can pass a log_level parameter
to the verifier
> Subject: Re: [RFC PATCH net-next 3/9] net: phy: Add phy_standalone sysfs entry
>
>
>
> On 5/22/2019 6:20 PM, Ioana Ciornei wrote:
> > Export a phy_standalone device attribute that is meant to give the
> > indication that this PHY lacks an attached_dev and its corresponding
> > sysfs link.
> >
On Sun, May 12, 2019 at 5:08 PM Roi Dayan wrote:
>
>
>
> On 06/05/2019 21:28, xiangxia.m@gmail.com wrote:
> > From: Tonghao Zhang
> >
> > In some case, we don't care the enc_src_ip and enc_dst_ip, and
> > if we don't match the field enc_src_ip and enc_dst_ip, we can use
> > fewer flows in har
Hi Rob,
On Thu, May 23, 2019 at 09:44:51AM -0500, Rob Herring wrote:
> > + reg:
> > +maxItems: 1
> > +minimum: 0
> > +maximum: 31
>
> min/max need to be under 'items'. I don't think these would ever be
> valid if the type is an array.
>
> I've modified the meta-schema to catch this.
On Fri, 24 May 2019 11:36:47 +0100
Quentin Monnet wrote:
> libbpf was recently made aware of the log_level attribute for programs,
> used to specify the level of information expected to be dumped by the
> verifier. Function bpf_prog_load_xattr() got support for this log_level
> parameter.
>
> Bu
Patched insns do not go through generic verification, therefore doesn't has
zero extension information collected during insn walking.
We don't bother analyze them at the moment, for any sub-register def comes
from them, just conservatively mark it as needing zero extension.
Signed-off-by: Jiong W
eBPF ISA specification requires high 32-bit cleared when low 32-bit
sub-register is written. This applies to destination register of ALU32 etc.
JIT back-ends must guarantee this semantic when doing code-gen. x86_64 and
AArch64 ISA has the same semantics, so the corresponding JIT back-end
doesn't ne
The encoding for this new variant is based on BPF_X format. "imm" field was
0 only, now it could be 1 which means doing zero extension unconditionally
.code = BPF_ALU | BPF_MOV | BPF_X
.dst_reg = DST
.src_reg = SRC
.imm = 1
We use this new form for doing zero extension for which verifier
v8:
- For stack slot read, mark them as REG_LIVE_READ64. (Alexei)
- Change DEF_NOT_SUBREG from -1 to 0. (Alexei)
- Rebased on top of latest bpf-next.
v7:
- Drop the first patch in v6, the one adding 32-bit return value and
argument type. (Alexei)
- Rename bpf_jit_hardware_zext to bpf
Cc: Björn Töpel
Acked-by: Björn Töpel
Tested-by: Björn Töpel
Signed-off-by: Jiong Wang
---
arch/riscv/net/bpf_jit_comp.c | 43 ++-
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/arch/riscv/net/bpf_jit_comp.c b/arch/riscv/net/bpf_jit_comp
Cc: Wang YanQing
Tested-by: Wang YanQing
Signed-off-by: Jiong Wang
---
arch/x86/net/bpf_jit_comp32.c | 83 +--
1 file changed, 56 insertions(+), 27 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp32.c b/arch/x86/net/bpf_jit_comp32.c
index b29e82f..133
x86_64 and AArch64 perhaps are two arches that running bpf testsuite
frequently, however the zero extension insertion pass is not enabled for
them because of their hardware support.
It is critical to guarantee the pass correction as it is supposed to be
enabled at default for a couple of other arc
After previous patches, verifier will mark a insn if it really needs zero
extension on dst_reg.
It is then for back-ends to decide how to use such information to eliminate
unnecessary zero extension code-gen during JIT compilation.
One approach is verifier insert explicit zero extension for those
Cc: Naveen N. Rao
Cc: Sandipan Das
Signed-off-by: Jiong Wang
---
arch/powerpc/net/bpf_jit_comp64.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp64.c
b/arch/powerpc/net/bpf_jit_comp64.c
index 21a1dcd..0ebd
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Signed-off-by: Jiong Wang
---
arch/s390/net/bpf_jit_comp.c | 41 ++---
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/arch/s390/net/bpf_jit_comp.c b/arch/s390/net/bpf_jit_comp.c
index 5e7c630..e636728
- bpf_fill_ld_abs_vlan_push_pop:
Prevent zext happens inside PUSH_CNT loop. This could happen because
of BPF_LD_ABS (32-bit def) + BPF_JMP (64-bit use), or BPF_LD_ABS +
EXIT (64-bit use of R0). So, change BPF_JMP to BPF_JMP32 and redefine
R0 at exit path to cut off the data-flow f
This patch randomizes high 32-bit of a definition when BPF_F_TEST_RND_HI32
is set.
Suggested-by: Alexei Starovoitov
Signed-off-by: Jiong Wang
---
kernel/bpf/verifier.c | 68 ++-
1 file changed, 57 insertions(+), 11 deletions(-)
diff --git a/kerne
Cc: David S. Miller
Signed-off-by: Jiong Wang
---
arch/sparc/net/bpf_jit_comp_64.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/sparc/net/bpf_jit_comp_64.c b/arch/sparc/net/bpf_jit_comp_64.c
index 65428e7..3364e2a 100644
--- a/arch/sparc
libbpf doesn't allow passing "prog_flags" during bpf program load in a
couple of load related APIs, "bpf_load_program_xattr", "load_program" and
"bpf_prog_load_xattr".
It makes sense to allow passing "prog_flags" which is useful for
customizing program loading.
Reviewed-by: Jakub Kicinski
Signed
The previous libbpf patch allows user to specify "prog_flags" to bpf
program load APIs. To enable high 32-bit randomization for a test, we need
to set BPF_F_TEST_RND_HI32 in "prog_flags".
To enable such randomization for all tests, we need to make sure all places
are passing BPF_F_TEST_RND_HI32. C
This patch eliminate zero extension code-gen for instructions including
both alu and load/store. The only exception is for ctx load, because
offload target doesn't go through host ctx convert logic so we do
customized load and ignores zext flag set by verifier.
Cc: Jakub Kicinski
Reviewed-by: Jak
Cc: Shubham Bansal
Signed-off-by: Jiong Wang
---
arch/arm/net/bpf_jit_32.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index c8bfbbf..97a6b4b 100644
--- a/arch/arm/net/bpf_j
2019-05-24 13:22 UTC+0200 ~ Jesper Dangaard Brouer
> On Fri, 24 May 2019 11:36:47 +0100
> Quentin Monnet wrote:
>
>> libbpf was recently made aware of the log_level attribute for programs,
>> used to specify the level of information expected to be dumped by the
>> verifier. Function bpf_prog_loa
If have an interface in vrf A:
10.10.2.0/24 dev ens9 proto kernel scope link src 10.10.2.2
local 10.10.2.2 dev ens9 proto kernel scope host src 10.10.2.2
and want to leak it into vrf B, it is not sufficient to leak just
the interface route:
ip route add 10.10.2.0/24 vrf B dev ens9
as traf
On Fri, 24 May 2019 12:51:14 +0100
Quentin Monnet wrote:
> 2019-05-24 13:22 UTC+0200 ~ Jesper Dangaard Brouer
> > On Fri, 24 May 2019 11:36:47 +0100
> > Quentin Monnet wrote:
> >
> >> libbpf was recently made aware of the log_level attribute for programs,
> >> used to specify the level of in
On Thu, 2019-05-23 at 13:36 -0600, Sean Tranchetti wrote:
> Currently, when resegmenting an unexpected UDP GRO packet, the full UDP
> checksum will be calculated for every new SKB created by skb_segment()
> because the netdev features passed in by udp_rcv_segment() lack any
> information about chec
On 5/23/19 5:31 PM, Jay Vosburgh wrote:
However, the logic in LACP will attach every slave of the bond
to an aggregator. If one or more slaves are connected to a specific
LACP peer, they will aggregate together. If any slave is connected to a
non-LACP peer, it will aggregate as an "ind
On 2019/5/24 下午6:07, Jesper Dangaard Brouer wrote:
On Fri, 24 May 2019 12:17:27 +0800
Jason Wang wrote:
Maybe this is acceptable, but it should be documented, as the current
assumption dictates: XDP program runs on the core where the XDP
frame/SKB was first seen.
At lest for TUN, this is n
On 23/05/2019 18:25, Jakub Kicinski wrote:
> Whether it's on you to fix this is debatable :) Since you're diving
> into actions and adding support for shared ones, I'd say it's time to
> rectify the situation.
>
> Let's look at it this way - if you fix the RTM_GETACTION you will
> necessarily add t
> > Hi Ioana
> >
> > Looking at the functions changed here, they seem to be related to
> > phy_attach(),
> > phy_connect(), and phy_detach() etc. Is the intention you can call these
> > functions and pass a NULL pointer for the net_device?
> >
> > Andrew
>
> Hi Andrew,
>
> Yes, the intenti
Hello,
On Fri, 24 May 2019, Jacky Hu wrote:
> Add checksum support for gue encapsulation with the tun_flags parameter,
> which could be one of the values below:
> IP_VS_TUNNEL_ENCAP_FLAG_NOCSUM
> IP_VS_TUNNEL_ENCAP_FLAG_CSUM
> IP_VS_TUNNEL_ENCAP_FLAG_REMCSUM
>
> Signed-off-by: Jacky Hu
> Hi Florian,
>
> Yes we could, but since most of the adjust_link -> phylink_mac_ops
> changes appear trivial, and we have the knowledge behind b53 right
> here, can't we just migrate everything in the next patchset and remove
> adjust_link altogether from DSA?
I agree with Florian, we either nee
On 2019/5/24 下午5:33, Jesper Dangaard Brouer wrote:
On Thu, 23 May 2019 13:15:44 -0700
Stephen Hemminger wrote:
On Thu, 23 May 2019 19:19:40 +
Saeed Mahameed wrote:
On Thu, 2019-05-23 at 10:54 -0700, Stephen Hemminger wrote:
When a device is stacked like (team, bonding, failsafe or ne
> On 24 May 2019, at 11:30, Toke Høiland-Jørgensen wrote:
>
> Hi Kevin
>
> I couldn't get 'git am' to accept your email. Not sure if it's because
> it's base64 encoded, or because it doesn't apply cleanly to current
> net-next.
Bizarre, haven’t changed the method by which I send in patches so
On Fri, May 24, 2019 at 11:25:03AM +1000, Greg Ungerer wrote:
> Hi Andrew,
>
> I have a problem with a Marvell 6390 switch that I have bisected
> back to commit 7cbbee050c95, "[PATCH] net: dsa: mv88e6xxx: Set correct
> interface mode for CPU/DSA ports".
>
> I have a Marvell 380 SoC based platform
On Fri, 24 May 2019 at 16:19, Andrew Lunn wrote:
>
> > Hi Florian,
> >
> > Yes we could, but since most of the adjust_link -> phylink_mac_ops
> > changes appear trivial, and we have the knowledge behind b53 right
> > here, can't we just migrate everything in the next patchset and remove
> > adjust
> Subject: Re: [RFC PATCH net-next 2/9] net: phy: Guard against the presence of
> a
> netdev
>
> > > Hi Ioana
> > >
> > > Looking at the functions changed here, they seem to be related to
> > > phy_attach(), phy_connect(), and phy_detach() etc. Is the intention
> > > you can call these function
On 24/05/2019 14:09, Edward Cree wrote:
> I'll put together an RFC patch, anyway
Argh, there's a problem: an action doesn't have a (directly) associated
block, and all the TC offload machinery nowadays is built around blocks.
Since this action might have been used in _any_ block (and afaik there's
Kevin 'ldir' Darbyshire-Bryant writes:
>> On 24 May 2019, at 11:30, Toke Høiland-Jørgensen wrote:
>>
>> Hi Kevin
>>
>> I couldn't get 'git am' to accept your email. Not sure if it's because
>> it's base64 encoded, or because it doesn't apply cleanly to current
>> net-next.
>
> Bizarre, haven’t
On 5/24/2019 3:35 AM, Max Uvarov wrote:
> PHY_INTERFACE_MODE_RGMII_RXID is less then TXID
> so code to set tx delay is never called.
>
> Signed-off-by: Max Uvarov
Could you provide an appropriate Fixes: tag for this as well as fix the
subject to be:
net: phy: dp83867: Set up RGMII TX delay
On 2019-05-24 9:57 a.m., Edward Cree wrote:
On 24/05/2019 14:09, Edward Cree wrote:
I'll put together an RFC patch, anyway
Argh, there's a problem: an action doesn't have a (directly) associated
block, and all the TC offload machinery nowadays is built around blocks.
Since this action might h
Backlog work for psock (sk_psock_backlog) might sleep while waiting
for memory to free up when sending packets. However, while sleeping
the socket may be closed and removed from the map by the user space
side.
This breaks an assumption in sk_stream_wait_memory, which expects the
wait queue to be s
On 5/24/19 2:15 AM, Jiri Pirko wrote:
>> Very cool stuff, \let's update devlink docs with the new potential
>> output of the fw flash commands, and show us some output example here
>> or on one of the commit messages, it would really help getting an idea
>> of what this cool patchset provides.
> Y
On 24/05/2019 15:44, Jamal Hadi Salim wrote:
> On 2019-05-24 9:57 a.m., Edward Cree wrote:
>> Argh, there's a problem: an action doesn't have a (directly) associated
>> block, and all the TC offload machinery nowadays is built around blocks.
>> Since this action might have been used in _any_ block
Smatch reports a potential spectre vulnerability in the dpaa2-eth
driver, where the value of rxnfc->fs.location (which is provided
from user-space) is used as index in an array.
Add a call to array_index_nospec() to sanitize the access.
Signed-off-by: Ioana Radulescu
---
drivers/net/ethernet/fr
Use PTR_ERR_OR_ZERO instead of PTR_ERR in cases where
zero is a valid input. Reported by smatch.
Signed-off-by: Ioana Radulescu
---
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-
Function dpaa2_eth_cls_key_size() expects a 64bit argument,
but DPAA2_ETH_DIST_ALL is defined as UINT_MAX. Fix this.
Signed-off-by: Ioana Radulescu
Reported-by: Dan Carpenter
---
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
2019-05-24 14:49 UTC+0200 ~ Jesper Dangaard Brouer
> On Fri, 24 May 2019 12:51:14 +0100
> Quentin Monnet wrote:
>
>> 2019-05-24 13:22 UTC+0200 ~ Jesper Dangaard Brouer
>>> On Fri, 24 May 2019 11:36:47 +0100
>>> Quentin Monnet wrote:
>>>
libbpf was recently made aware of the log_level a
Fix a couple of warnings reported by smatch.
Ioana Radulescu (3):
dpaa2-eth: Fix potential spectre issue
dpaa2-eth: Use PTR_ERR_OR_ZERO where appropriate
dpaa2-eth: Make constant 64-bit long
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 4 ++--
drivers/net/ethernet/freescale/dpaa2
On 5/24/19 3:36 AM, Quentin Monnet wrote:
> Hi,
> This series adds an option to bpftool to make it print additional
> information via libbpf and the kernel verifier when attempting to load
> programs.
>
> A new API function is added to libbpf in order to pass the log_level from
> bpftool with th
Jakub Sitnicki wrote:
> On Thu, May 23, 2019 at 05:58 PM CEST, John Fastabend wrote:
> > [...]
> >
> >>
> >> Thanks for taking a look at it. Setting MSG_DONTWAIT works great for
> >> me. No more crashes in sk_stream_wait_memory. I've tested it on top of
> >> current bpf-next (f49aa1de9836). Here's
1 - 100 of 234 matches
Mail list logo
