From: Greg Ungerer
Add descriptive entries for the new bindings introduced to support the
MT7530 implementation in the MediaTek MT7621 SoC.
New bindings added for:
mediatek,no-clock-regulator
mediatek,mfc-has-cpuport
Signed-off-by: Greg Ungerer
---
From: Greg Ungerer
At least one device that contains the MediaTek MT7530 switch module
does not need the clock and regulator setup parts of the MT7530 DSA
driver. That setup looks to be very specific to the MT7623.
The MediaTek MT7621 SoC device contains a 7530 switch, but its MIPS CPU
cores
From: Greg Ungerer
Some versions of the MediaTek MT7530 switch have a CPU port number and
enable bit in their MFC register. The MT7530 instance on the MediaTek
MT7621 SoC is one that does for example. The switch will not work
without these fields being correctly setup on these devices.
Create a
I have been working towards supporting the MT7530 switch as used in the
MediaTek MT7621 SoC. Unlike the MediaTek MT7623 the MT7621 is built around
a dual core MIPS CPU architecture. But underneath it is what appears to
be the same 7530 switch.
The following 3 patches are more of an RFC than
> > > So it should return at least 18 and not 14.
> >
> > Yes, the function does its best to return at least 18, but it silently
> expects
> > skb_transport_offset to exceed 18. In normal conditions, it will be more
> that
> > 18, because it will be at least 14 + 20. But in my case, when I send a
On Thu, Nov 29, 2018 at 11:39 PM Neil Horman wrote:
>
> On Thu, Nov 29, 2018 at 02:42:56PM +0800, Xin Long wrote:
> > Now when using stream reconfig to add out streams, stream->out
> > will get re-allocated, and all old streams' information will
> > be copied to the new ones and the old ones will
On 2018/11/30 11:40, Jason Wang wrote:
> On 2018/11/30 上午10:30, 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
On Fri, Nov 30, 2018 at 5:52 AM Neil Horman wrote:
>
> On Thu, Nov 29, 2018 at 02:44:07PM +0800, Xin Long wrote:
> > Without holding transport to dereference its asoc, a use after
> > free panic can be caused in sctp_epaddr_lookup_transport. Note
> > that a sock lock can't protect these
Make it set the flag argument to bpf_verify_program() which will relax
the alignment restrictions.
Now all such test cases will go properly through the verifier even on
inefficient unaligned access architectures.
On inefficient unaligned access architectures do not try to run such
programs,
Use F_NEEDS_EFFICIENT_UNALIGNED_ACCESS in more tests where the
expected result is REJECT.
Signed-off-by: David S. Miller
---
tools/testing/selftests/bpf/test_verifier.c | 44 +
1 file changed, 44 insertions(+)
diff --git
If a testcase has alignment problems but is expected to be ACCEPT,
verify it using F_NEEDS_EFFICIENT_UNALIGNED_ACCESS too.
Maybe in the future if we add some architecture specific code to elide
the unaligned memory access warnings during the test, we can execute
these as well.
Signed-off-by:
On sparc64 a ton of test cases in test_verifier.c fail because
the memory accesses in the test case are unaligned (or cannot
be proven to be aligned by the verifier).
Perhaps we can eventually try to (carefully) modify each test case
which has this problem to not use unaligned accesses but:
1)
Often we want to write tests cases that check things like bad context
offset accesses. And one way to do this is to use an odd offset on,
for example, a 32-bit load.
This unfortunately triggers the alignment checks first on platforms
that do not set CONFIG_EFFICIENT_UNALIGNED_ACCESS. So the
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Vinicius Costa Gomes
> Sent: Friday, November 16, 2018 4:19 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; jesus.s.palen...@gmail.com
> Subject: [Intel-wired-lan] [next-queue PATCH v1 2/2]
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Vinicius Costa Gomes
> Sent: Friday, November 16, 2018 4:19 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Sanchez-Palencia, Jesus ; Kirsher,
> Jeffrey T ; netdev@vger.kernel.org;
>
On 2018/11/30 上午10:30, 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 variable and
then use it
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 variable and
then use it after netif_receive_skb(). IMO using xdp data size
From: Daniel Borkmann
Date: Fri, 30 Nov 2018 03:01:38 +0100
> The following pull-request contains BPF updates for your *net-next* tree.
>
> (Getting out bit earlier this time to pull in a dependency from bpf.)
>
> The main changes are:
>
> 1) Add libbpf ABI versioning and document API naming
On Thu, Nov 29, 2018 at 1:46 PM Eric Dumazet wrote:
>
>
>
> On 11/29/2018 01:13 PM, Duyck, Alexander H wrote:
>
> > Instead of just checking for the max it might make more sense to do a
> > check using skb_is_gso, and then if true use gso_segs, otherwise just
> > default to 1.
> >
> > Also your
Hi David,
The following pull-request contains BPF updates for your *net-next* tree.
(Getting out bit earlier this time to pull in a dependency from bpf.)
The main changes are:
1) Add libbpf ABI versioning and document API naming conventions
as well as ABI versioning process, from Andrey.
On 11/30/2018 12:47 AM, Jakub Kicinski wrote:
> On Thu, 29 Nov 2018 15:31:45 -0800, Yonghong Song wrote:
>> During porting libbpf to bcc, I got some warnings like below:
>> ...
>> [ 2%] Building C object
>> src/cc/CMakeFiles/bpf-shared.dir/libbpf/src/libbpf.c.o
>>
> From: Eric Dumazet
> On 11/29/2018 01:13 PM, Duyck, Alexander H wrote:
> >
> > Also your bytes are going to be totally messed up as well since the
> > headers are trimmed in the GSO frames. It might be worthwhile to just
> > have a branch based on skb_is_gso that sets the packets and bytes
> >
On Wed, Nov 28, 2018 at 3:10 AM Maxim Mikityanskiy wrote:
>
> Hi Saeed,
>
> > Can you elaborate more, what NIC? what configuration ? what do you mean
> > by confusion, anyway please see below
>
> ConnectX-4, after running `mlnx_qos -i eth1 --trust dscp`, which sets inline
> mode 2
Fix packet count when using vlan/macvlan drivers with gso. Without this it
is not possible to reconcile packet counts between underlying devices and
these virtual devices. Additionally, the output looks wrong in a standalone
way i.e. device MTU of 1500, 1 packet sent, 31856 bytes sent.
There are
On Mon, Nov 26, 2018 at 2:39 PM Saeed Mahameed wrote:
>
> Hi,
>
> This patchset is for mlx5-next shared branch, and will be applied there
> once the review is done.
>
> The main idea of this change is to define a flexible scalable and
> simpler high level mlx5 core APIs to forward device and
Improve the wording around socket lookup for reuseport sockets, and
ensure that both bpf.h headers are in sync.
Signed-off-by: Joe Stringer
---
include/uapi/linux/bpf.h | 4
tools/include/uapi/linux/bpf.h | 8
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git
David Ahern and Nicolas Dichtel report that the handling of the netns id
0 is incorrect for the BPF socket lookup helpers: rather than finding
the netns with id 0, it is resolving to the current netns. This renders
the netns_id 0 inaccessible.
To fix this, adjust the API for the netns to treat
On Wed, Nov 28, 2018 at 8:09 PM Eric Dumazet wrote:
>
> On Wed, Nov 28, 2018 at 7:53 PM Cong Wang wrote:
> >
> > On Wed, Nov 28, 2018 at 7:50 PM Eric Dumazet wrote:
> > >
> > > On Wed, Nov 28, 2018 at 7:40 PM Cong Wang
> > > wrote:
> > > >
> > > > On Wed, Nov 28, 2018 at 4:07 PM Eric Dumazet
From: Christoph Paasch
Date: Thu, 29 Nov 2018 16:01:04 -0800
> __qdisc_drop_all() accesses skb->prev to get to the tail of the
> segment-list.
>
> With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
> the skb-list handling has been changed to set skb->next to NULL and set
> the
On 11/29/2018 04:01 PM, Christoph Paasch wrote:
> __qdisc_drop_all() accesses skb->prev to get to the tail of the
> segment-list.
>
> With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
> the skb-list handling has been changed to set skb->next to NULL and set
> the list-poison
On Wed, Nov 28, 2018 at 4:05 PM Cong Wang wrote:
>
> On Wed, Nov 28, 2018 at 3:57 PM Cong Wang wrote:
> > But again, I kinda feel the hardware already does the sanity check,
> > otherwise we have much more serious trouble in mlx5e_lro_update_hdr()
> > which parses into TCP header.
> >
>
> While
__qdisc_drop_all() accesses skb->prev to get to the tail of the
segment-list.
With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
the skb-list handling has been changed to set skb->next to NULL and set
the list-poison on skb->prev.
With that change, __qdisc_drop_all() will panic
On Thu, Nov 29, 2018 at 3:54 PM David Miller wrote:
>
> From: Eric Dumazet
> Date: Thu, 29 Nov 2018 15:09:18 -0800
>
> > diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
> > index
> > 2c38e3d0792468162ee0dc4137f1400160ab9276..22cd46a600576f286803536d45875cd9d537cdca
> > 100644
> >
From: Christoph Paasch
Date: Thu, 29 Nov 2018 15:45:19 -0800
> I can resubmit a patch.
Please do after testing.
On Thu, Nov 29, 2018 at 5:13 AM Tariq Toukan wrote:
>
>
>
> On 29/11/2018 1:04 AM, Cong Wang wrote:
> > IP header is not necessarily located right after struct ethhdr,
> > there could be multiple 802.1Q headers in between, this is why
> > we call __vlan_get_protocol().
> >
> > Fixes: fe1dc069990c
From: Eric Dumazet
Date: Thu, 29 Nov 2018 15:09:18 -0800
> diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
> index
> 2c38e3d0792468162ee0dc4137f1400160ab9276..22cd46a600576f286803536d45875cd9d537cdca
> 100644
> --- a/net/sched/sch_netem.c
> +++ b/net/sched/sch_netem.c
> @@ -431,6
On Thu, 29 Nov 2018 15:31:45 -0800, Yonghong Song wrote:
> During porting libbpf to bcc, I got some warnings like below:
> ...
> [ 2%] Building C object
> src/cc/CMakeFiles/bpf-shared.dir/libbpf/src/libbpf.c.o
> /home/yhs/work/bcc2/src/cc/libbpf/src/libbpf.c:12:0:
> warning:
On 29/11/18 - 15:09:18, Eric Dumazet wrote:
>
>
> On 11/29/2018 02:55 PM, Christoph Paasch wrote:
> > On 29/11/18 - 14:44:44, Eric Dumazet wrote:
> >>
> >>
> >> On 11/29/2018 02:27 PM, Christoph Paasch wrote:
> >>> There are places in the stack, where we access skb->prev directly and
> >>>
During porting libbpf to bcc, I got some warnings like below:
...
[ 2%] Building C object
src/cc/CMakeFiles/bpf-shared.dir/libbpf/src/libbpf.c.o
/home/yhs/work/bcc2/src/cc/libbpf/src/libbpf.c:12:0:
warning: "_GNU_SOURCE" redefined [enabled by default]
#define _GNU_SOURCE
...
[
On Wed, Jun 6, 2018 at 1:21 AM Yves-Alexis Perez wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Tue, Jun 05, 2018 at 10:54:51AM +0200, Yves-Alexis Perez wrote:
> > Hi,
> >
> > since some kernels releases (I didn't test thorougly but at least 4.16
> > and 4.17) I have regular
On 11/29/18 1:00 PM, Jakub Kicinski wrote:
> On Thu, 29 Nov 2018 12:38:03 -0800, Yonghong Song wrote:
>> diff --git a/tools/lib/bpf/libbpf_errno.c b/tools/lib/bpf/libbpf_errno.c
>> index d83b17f8435c..286e497c50ec 100644
>> --- a/tools/lib/bpf/libbpf_errno.c
>> +++ b/tools/lib/bpf/libbpf_errno.c
On 11/29/2018 03:00 PM, Paolo Abeni wrote:
> 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
On 11/29/2018 02:55 PM, Christoph Paasch wrote:
> On 29/11/18 - 14:44:44, Eric Dumazet wrote:
>>
>>
>> On 11/29/2018 02:27 PM, Christoph Paasch wrote:
>>> There are places in the stack, where we access skb->prev directly and
>>> modify it. Namely, __qdisc_drop_all().
>>>
>>> With commit
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 buildin, it will be checked first,
so we have a single additional compare for the more common path.
Signed-off-by: Paolo Abeni
---
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 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 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 macro defined here implement
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.
This may lead to some uglification around the
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?
This would request an additional lookup, and heavy duty servers using
non connected sockets
would pay the price for an extra lookup for
On 29/11/18 - 14:44:44, Eric Dumazet wrote:
>
>
> On 11/29/2018 02:27 PM, Christoph Paasch wrote:
> > There are places in the stack, where we access skb->prev directly and
> > modify it. Namely, __qdisc_drop_all().
> >
> > With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
> >
On Thu, 2018-11-29 at 22:19 +, Steve Douthit wrote:
> On 11/29/18 2:03 PM, Jeff Kirsher wrote:
> > On Thu, 2018-11-29 at 18:54 +, Steve Douthit wrote:
> > > Most dsa devices currently expect to get a pointer to a mii_bus from
> > > platform data of device tree information.
> > >
> > > The
Hello,
On 28/11/18 - 19:15:12, Eric Dumazet wrote:
> On Wed, Nov 28, 2018 at 7:09 PM Jana Iyengar wrote:
> >
> >
> > On Wed, Nov 28, 2018 at 6:19 PM Eric Dumazet wrote:
> >>
> >> On Wed, Nov 28, 2018 at 5:57 PM Christoph Paasch wrote:
> >> >
> >> > There are use-cases where a host wants to use
On 11/29/2018 02:27 PM, Christoph Paasch wrote:
> There are places in the stack, where we access skb->prev directly and
> modify it. Namely, __qdisc_drop_all().
>
> With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
> the skb-list handling has been changed to set skb->next to
On Wed, Nov 28, 2018 at 9:44 AM Davide Caratti wrote:
>
> when users set an invalid control action, kmemleak complains as follows:
...
> change tcf_police_init() to avoid leaking 'new' in case TCA_POLICE_RESULT
> contains TC_ACT_GOTO_CHAIN extended action.
>
> Fixes: c08f5ed5d625 ("net/sched:
There are places in the stack, where we access skb->prev directly and
modify it. Namely, __qdisc_drop_all().
With commit 68d2f84a1368 ("net: gro: properly remove skb from list")
the skb-list handling has been changed to set skb->next to NULL and set
the list-poison on skb->prev.
With that
On 11/29/18 2:03 PM, Jeff Kirsher wrote:
> On Thu, 2018-11-29 at 18:54 +, Steve Douthit wrote:
>> Most dsa devices currently expect to get a pointer to a mii_bus from
>> platform data of device tree information.
>>
>> The first patch exposes a mii_bus for ixgbe devices.
>>
>> Currently the
From: Cong Wang
Date: Mon, 26 Nov 2018 09:31:26 -0800
> Cc: Herbert Xu
> Signed-off-by: Cong Wang
Applied, thanks Cong.
On Thu, Nov 29, 2018 at 11:31:23AM -0800, Florian Fainelli wrote:
>
>
> On 11/29/2018 4:49 AM, Baruch Siach wrote:
> > The mvpp2_phylink_validate() relies on the interface field of
> > phylink_link_state to determine valid link modes. However, when called
> > from phylink_sfp_module_insert()
Hi Cong,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net/master]
url:
https://github.com/0day-ci/linux/commits/Cong-Wang/mlx5-fixup-checksum-for-ethernet-padding/20181130-014928
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC)
On 11/29/2018 01:13 PM, Duyck, Alexander H wrote:
> Instead of just checking for the max it might make more sense to do a
> check using skb_is_gso, and then if true use gso_segs, otherwise just
> default to 1.
>
> Also your bytes are going to be totally messed up as well since the
> headers
On Thu, 2018-11-29 at 15:58 -0500, Debabrata Banerjee wrote:
> Fix packet count when using vlan/macvlan drivers with gso. Without this it
> is not possible to reconcile packet counts between underlying devices and
> these virtual devices. Additionally, the output looks wrong in a standalone
> way
On Thu, 29 Nov 2018 12:38:03 -0800, Yonghong Song wrote:
> diff --git a/tools/lib/bpf/libbpf_errno.c b/tools/lib/bpf/libbpf_errno.c
> index d83b17f8435c..286e497c50ec 100644
> --- a/tools/lib/bpf/libbpf_errno.c
> +++ b/tools/lib/bpf/libbpf_errno.c
> @@ -40,9 +40,19 @@ int libbpf_strerror(int err,
Fix packet count when using vlan/macvlan drivers with gso. Without this it
is not possible to reconcile packet counts between underlying devices and
these virtual devices. Additionally, the output looks wrong in a standalone
way i.e. device MTU of 1500, 1 packet sent, 31856 bytes sent.
There are
On Thu, Nov 29, 2018 at 02:44:07PM +0800, Xin Long wrote:
> Without holding transport to dereference its asoc, a use after
> free panic can be caused in sctp_epaddr_lookup_transport. Note
> that a sock lock can't protect these transports that belong to
> other socks.
>
> A similar fix as Commit
On Thu, 29 Nov 2018 03:22:24 +0100, Pablo Neira Ayuso wrote:
> This patch provides the flow_stats structure that acts as container for
> tc_cls_flower_offload, then we can use to restore the statistics on the
> existing TC actions. Hence, tcf_exts_stats_update() is not used from
> drivers anymore.
During porting libbpf to bcc, I got some warnings like below:
...
[ 2%] Building C object
src/cc/CMakeFiles/bpf-shared.dir/libbpf/src/libbpf.c.o
/home/yhs/work/bcc2/src/cc/libbpf/src/libbpf.c:12:0:
warning: "_GNU_SOURCE" redefined [enabled by default]
#define _GNU_SOURCE
...
[
On Thu, Nov 29, 2018 at 3:26 PM 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
On Thu, Nov 29, 2018 at 3:26 PM 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 MTU.
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 of
the skbs, because it can build, send and free skbs within its loop,
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 MTU. With segmentation offload building
larger datagrams, the benefit of
From: Willem de Bruijn
Both msg_zerocopy and udpgso_bench have udp zerocopy variants.
Exercise these as part of the standard kselftest run.
With udp, msg_zerocopy has no control channel. Ensure that the
receiver exits after the sender by accounting for the initial
delay in starting them (in
From: Willem de Bruijn
Enable MSG_ZEROCOPY for udp sockets
Patch 1/3 is the main patch, a rework of RFC patch
http://patchwork.ozlabs.org/patch/899630/
more details in the patch commit message
Patch 2/3 is an optimization to remove a branch from the UDP hot path
and
Hi Roopa,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Roopa-Prabhu/vxlan-support-changelink-for-a-few-more-attributes/20181130-030315
config: x86_64-randconfig-x006-201847 (attached as .config)
Hi Florian,
Florian Fainelli writes:
> On 11/29/2018 4:49 AM, Baruch Siach wrote:
>> The mvpp2_phylink_validate() relies on the interface field of
>> phylink_link_state to determine valid link modes. However, when called
>> from phylink_sfp_module_insert() this field in not initialized. The
>>
From: Baruch Siach
Date: Thu, 29 Nov 2018 12:00:05 +0200
> SFP standards are now available from the SNIA (Storage Networking
> Industry Association) website.
>
> Cc: Andrew Lunn
> Cc: Florian Fainelli
> Signed-off-by: Baruch Siach
Applied.
On Thu, Nov 29, 2018 at 12:00:05PM +0200, Baruch Siach wrote:
> SFP standards are now available from the SNIA (Storage Networking
> Industry Association) website.
>
> Cc: Andrew Lunn
> Cc: Florian Fainelli
> Signed-off-by: Baruch Siach
Reviewed-by: Andrew Lunn
Andrew
On 11/29/2018 4:49 AM, Baruch Siach wrote:
> The mvpp2_phylink_validate() relies on the interface field of
> phylink_link_state to determine valid link modes. However, when called
> from phylink_sfp_module_insert() this field in not initialized. The
> default switch case then excludes 10G link
From: Eric Dumazet
Date: Thu, 29 Nov 2018 07:56:20 -0800
> We can remove the loop and conditional branches
> and compute wscale efficiently thanks to ilog2()
>
> Signed-off-by: Eric Dumazet
Applied.
From: Sabrina Dubroca
Date: Thu, 29 Nov 2018 14:14:47 +0100
> This fixes some bugs introduced by the "Symmetric queue selection
> using XPS for Rx queues".
>
> First, the refactoring of the cleanup function skipped resetting the
> queue's NUMA node under some conditions.
>
> Second, the
On Thu, 2018-11-29 at 18:54 +, Steve Douthit wrote:
> Most dsa devices currently expect to get a pointer to a mii_bus from
> platform data of device tree information.
>
> The first patch exposes a mii_bus for ixgbe devices.
>
> Currently the ixgbe driver only allows accesses to the probed
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 | 29 +--
1 file changed, 14 insertions(+),
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/ixgbe/ixgbe.h | 2 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 192
Most dsa devices currently expect to get a pointer to a mii_bus from
platform data of device tree information.
The first patch exposes a mii_bus for ixgbe devices.
Currently the ixgbe driver only allows accesses to the probed PHY
address via ioctls. The second patch changes that behavior to
On 11/29/18 11:50 AM, Stephen Hemminger wrote:
> PS: ss still doesn't support JSON output, given the volume of output it would
> be good.
I thought Stefano was investigating it as an alternative to the 'display
selected columns' patches.
On Thu, 29 Nov 2018 02:27:54 -0800
Eric Dumazet wrote:
> Wei Wang added these fields in linux-4.19
>
> Tested:
>
> ss -ti ...
>
> ts sack cubic wscale:8,8 rto:7 rtt:2.678/0.267 mss:1428 pmtu:1500
> rcvmss:536 advmss:1428 cwnd:91 ssthresh:65
> (*) bytes_sent:17470606104
From: Baruch Siach
Date: Thu, 29 Nov 2018 12:40:11 +0200
> The link modes that sfp_parse_support() detects are stored in the
> 'modes' bitmap. There is no reason to make an exception for 1000Base-PX
> or 1000Base-BX10.
>
> Signed-off-by: Baruch Siach
Applied and queued up for -stable.
From: Michael Shteinbok
Date: Thu, 29 Nov 2018 10:50:19 +0200
> skb_linearization can fail due to memory allocation failure.
> In such a case, the driver will drop the packet. In such a case
> The driver used to print an error message.
> This patch replaces this error message by a dedicated
From: Ioana Ciocoi Radulescu
Date: Thu, 29 Nov 2018 08:43:40 +
> Add comments in the switch statement for XDP action to indicate
> fallthrough is intended.
>
> Signed-off-by: Ioana Radulescu
Applied.
On Thu, Nov 29, 2018 at 2:28 AM Eric Dumazet wrote:
>
> Wei Wang added these fields in linux-4.19
>
> Tested:
>
> ss -ti ...
>
> ts sack cubic wscale:8,8 rto:7 rtt:2.678/0.267 mss:1428 pmtu:1500
> rcvmss:536 advmss:1428 cwnd:91 ssthresh:65
> (*) bytes_sent:17470606104
Thu, Nov 29, 2018 at 04:47:07PM CET, john.fastab...@gmail.com wrote:
>On 11/28/18 6:22 PM, Pablo Neira Ayuso wrote:
>> Hi,
>>
>> This patchset is another iteration to introduce an in-kernel intermediate
>> representation (IR) to express ACL hardware offloads [1] [2] [3].
>>
>
>Hi,
>
>Also wanted
On Thu, 2018-11-29 at 01:54 +, Yang Xiao wrote:
> From: Young Xiao
>
> If ice driver has q_vectors w/ active NAPI that has no rings,
> then this will result in a divide by zero error. To correct it
> I am updating the driver code so that we only support NAPI on
> q_vectors that have 1 or
On Thu, Nov 29, 2018 at 12:06:18PM +0100, Nicolas Dichtel wrote:
> Le 28/11/2018 à 22:48, Andrew Lunn a écrit :
> > On Wed, Nov 28, 2018 at 07:12:56PM +0100, Nicolas Dichtel wrote:
> >> The userspace may need to control the carrier state.
> >
> > Hi Nicolas
> Hi Andrew,
>
> >
> > Could you
On Thu, Nov 29, 2018 at 3:27 AM Paolo Abeni wrote:
>
> Hi,
>
> Thank you for the update!
>
> On Wed, 2018-11-28 at 18:50 -0500, Willem de Bruijn wrote:
> > I did revert to the basic implementation using an extra ref
> > for the function call, similar to TCP, as you suggested.
> >
> > On top of
On Thu, Nov 29, 2018 at 7:55 AM Sabrina Dubroca wrote:
>
> 2018-11-29, 07:27:17 -0800, Roopa Prabhu wrote:
> > On Thu, Nov 29, 2018 at 6:19 AM Sabrina Dubroca
> > wrote:
> > > 2018-11-28, 14:27:59 -0800, Roopa Prabhu wrote:
> > > nit: This patch would have been easier to review if it came first
On Thu, Nov 29, 2018 at 10:56 AM Eric Dumazet wrote:
>
> We can remove the loop and conditional branches
> and compute wscale efficiently thanks to ilog2()
>
> Signed-off-by: Eric Dumazet
Acked-by: Soheil Hassas Yeganeh
Very nice, thank you, Eric!
> ---
> net/ipv4/tcp_output.c | 8 +++-
We can remove the loop and conditional branches
and compute wscale efficiently thanks to ilog2()
Signed-off-by: Eric Dumazet
---
net/ipv4/tcp_output.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index
2018-11-29, 07:27:17 -0800, Roopa Prabhu wrote:
> On Thu, Nov 29, 2018 at 6:19 AM Sabrina Dubroca wrote:
> > 2018-11-28, 14:27:59 -0800, Roopa Prabhu wrote:
> > nit: This patch would have been easier to review if it came first in
> > the series. Converting:
>
> I considered that. But the first
2018-11-29, 07:33:11 -0800, Roopa Prabhu wrote:
> On Thu, Nov 29, 2018 at 5:56 AM Sabrina Dubroca wrote:
> >
> > 2018-11-28, 14:27:57 -0800, Roopa Prabhu wrote:
> > > From: Roopa Prabhu
> > >
> > > We started very conservative when supporting changelink
> > > especially because not all attribute
On 11/28/18 6:22 PM, Pablo Neira Ayuso wrote:
> Hi,
>
> This patchset is another iteration to introduce an in-kernel intermediate
> representation (IR) to express ACL hardware offloads [1] [2] [3].
>
Hi,
Also wanted to add. In an earlier thread it was mentioned this could be
used for other
Support for UDP fragmentation offloading was removed in kernel v4.14.
The ethtool reports incorrectly its state on this and newer kernels:
$ ethtool -k enp0s31f6 | grep udp-frag
udp-fragmentation-offload: off
It's look like that the feature is supported and disabled only. Instead
of this
1 - 100 of 135 matches
Mail list logo
